[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

Peter Hutterer  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|REOPENED|RESOLVED

--- Comment #6 from Peter Hutterer  ---
(In reply to oiaohm from comment #5)
> The specific use-case is two fold.   When firmware changes on input devices
> or devices effecting input devices calibration for them can now be wrong.
> [...]

but we won't know that ahead of time or even without the user confirming.
All we know is "something has changed" but we cannot know anything else.

and given the number of devices and frequency of updates, this means we'll
have a 99%+ false positive rate if we assume because the fw has changed the
devices now work differently.

> The other is when something fails we can have the horible event where the
> report a bug here since they have booted into windows and when they boot
> back into Linux the problem is gone.   Why Windows updated firmware to break
> it and then updated it and fixed it.   Since there is no log of firmware
> changes the bug will end up not being correctly identified.

I agree, there should be a good way to log whatever the applicable firmware
version is in a bug report for comparsion purposes. whether that should be
(stored) in libinput is questionable.

> A firmware list on most systems should be fairly much static most of the
> time.
> 
> Like leaving on the list items that are not always plugged in but you have
> seen before would be fine.

fwiw, libinput has no local storage mechanism and is unlikely to ever get one.

> Not all issues require quirk fixes.   Some can be like the device use to
> require sensitivity x it now requires y and that due to firmware change.  
> How with current libinput design with firmware change will users know they
> are meant to check calibration.   Due to Windows 10 I cannot see any way of
> doing it without without storing a list to compare against.

calibration (if any) should be stored in the compositor. When the FW is
updated and you notice the calibration is out, use the calibration tool
provded by the compositor/DE to re-calibrate and that's done. There is no
benefit of knowing about the FW changes - either the calibration is out and
we have to ask the user to recalibrate anyway or it's still the same in
which case any warning would be a false positive.

> I do have a question.
> prop_value(device, "PRODUCT")
> If we don't decode this and the input device is plugged into the same place
> as long as firmware has not changed this would remain identical right.

the product is bus type and vid/pid and version number (if any). This does
not change regardless where it's plugged in unless the device switches
between e.g. USB and Bluetooth.

> Line 68
> printf("LIBINPUT_MODEL_FIRMWARE_VERSION=%x\n", version)
> This does not line up really to comment on 
> 66 /* ALPS' firmware version is the version */
> then 
> handle_touchpad_synaptics its process product again this time you don't
> print the version value.

only the alps driver exports the firmware version in the version field.

> This is why there need to be a generic rule on the project for what to-do
> when you find firmware version information covering how it will be
> logged/stored and used.  So that you don't have like
> handle_touchpad_synaptics and handle_touchpad_alps doing different things.
> 
> "Support for Firmware Version Detection" that is usable to end user in case
> of problem.   Libinput is internally using firmware version information this
> is correct but its not putting the information out for the user to use.

nope, it won't help. for example, we have a specific case where the firmware
on one device is broken but the exact same firmware (at least the numbers we
get from the kernel) is broken on another device. Or more specifically, what
matters is the tuple of firmware version and board version.

Look, I don't disagree that having reliable firmware detection etc. is a
useful thing to have, but right now we don't have a way or plan on how to do
this. Which is always a precondition for getting it badly wrong.

Feel free to go ahead with trying to figure out how to do this. You can
easily store information in udev for devices where libinput can get to it.
That way the firmware bits can be completely separate from libinput and once
we have some good format/version/detection/... we can have libinput rely on
it. but right now, all this is a blue sky "it'd be nice to have even though
we don't know what we want".

> --And what do we do with this information? This is something we can do when
> there's a specific use-case, but just storing it for the sake of having it
> doesn't help.--
> 
> This is case of not having it make solving what is going wrong harder.  Its
> not always useful 

[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

--- Comment #5 from oia...@gmail.com ---
Problem here Peter Hutterer is back tracing issues is going to get harder.

--And what do we do with this information? This is something we can do when
there's a specific use-case, but just storing it for the sake of having it
doesn't help.--

The specific use-case is two fold.   When firmware changes on input devices or
devices effecting input devices calibration for them can now be wrong.  Like
set too sensitive or not sensitive enough.   Of course user might think there
system is slow or unresponsive or over sensitive and all it is that it need
them to run a recalibration.   Problem here is the user may not straight way
pick up that they need to check calibration unless they are informed.  Like the
booted into windows 10 and windows 10 decided to automatically apply updates
and updated firmware totally not informing the user what has happened. 

The other is when something fails we can have the horible event where the
report a bug here since they have booted into windows and when they boot back
into Linux the problem is gone.   Why Windows updated firmware to break it and
then updated it and fixed it.   Since there is no log of firmware changes the
bug will end up not being correctly identified.

So on input devices giving a user notice to consider checking sensitivity and
functionality would be a good thing after a firmware change but we cannot
expect users to know that a firmware change has happened unless something
exists to inform them.

So not storing firmware version information causes black hole of issues.   
This was not a problem when users had to go out of their way to particularly
update firmware.   Windows 10 and auto updates changed the playing field due to
how much is happening without users being aware of it.

A firmware list on most systems should be fairly much static most of the time.

Like leaving on the list items that are not always plugged in but you have seen
before would be fine.

What happens under windows with some drawing tablets when they have been
firmware updates on one Windows machine then plugged into one that had seen it
before you now see that windows machine install new driver.   Kinda underhanded
way of saying to user hey that old device you had is no longer configured go
reconfigure it.

Not all issues require quirk fixes.   Some can be like the device use to
require sensitivity x it now requires y and that due to firmware change.   How
with current libinput design with firmware change will users know they are
meant to check calibration.   Due to Windows 10 I cannot see any way of doing
it without without storing a list to compare against.


I do have a question.
prop_value(device, "PRODUCT")
If we don't decode this and the input device is plugged into the same place as
long as firmware has not changed this would remain identical right.

So if we are only looking for difference event to info user that something has
change and run calibration/diagnostics I don't see it needing massively
complex.   If the device has changed where it connected user still should be
advised to check calibration not all USB ports are created equal on
performance.

Line 68
printf("LIBINPUT_MODEL_FIRMWARE_VERSION=%x\n", version)
This does not line up really to comment on 
66 /* ALPS' firmware version is the version */
then 
handle_touchpad_synaptics its process product again this time you don't print
the version value.


This is the current inconsistency.   If you are going to print out the version
of the firmware for 1 bit of hardware and log it do it for all hardware.  
Writing this into a plan log that is never compared is limited usage to end
user.

The problem I currently have is you have inconstancy logging firmware
information and worst at time how it logged is not 100 percent clear what it is
without reading the source code. 

This is why there need to be a generic rule on the project for what to-do when
you find firmware version information covering how it will be logged/stored and
used.  So that you don't have like handle_touchpad_synaptics and
handle_touchpad_alps doing different things.


"Support for Firmware Version Detection" that is usable to end user in case of
problem.   Libinput is internally using firmware version information this is
correct but its not putting the information out for the user to use.

Now if you write log of the firmwares and the devices and compare is possible
so end user can be informed in case of change this is useful.   So the computer
does not appear to be magically changing behavour on the end user.

I have had wacky due to a single sector failing in a swap partition and a
different time bit failures in ram.  Currently how would I know that libinput
played up on X day because due to a bad bit of ram saw hardware information
that was completely wrong.

Support for Firmware Version Detection the topic of this bug what I am asking
for is that firmware version 

[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

--- Comment #4 from Peter Hutterer  ---
Please don't re-open RFE bugs closed by a maintainer unless you have intentions
of working on this in the foreseeable future.

(In reply to oiaohm from comment #3)
> At a min I think libinput should store and check the SMBIOS/DMI inform to
> check the bios/UEFI on a x86 system.As this is one thing that EFI
> standard is pushing that OS like Windows will update.

And what do we do with this information? This is something we can do when
there's a specific use-case, but just storing it for the sake of having it
doesn't help.

> If this does not have a place in libinput it need a home somewhere.

The way we work with similar cases so far is have udev property tag devices
where we need specific quirks. So this could be part of udev, or any external
project provided it adds to udev properties.


> --The FW version is afaict a free-form string--
> I don't see where it being a free-form string is a problem.   [..]

A free-form string cannot be reliably compared for correct increments,
specifically because we don't care about how the string looks like per se but
rather the information that the string implies. For example, "fw84xx23s" may
imply "this touchpad doesn't tag multiple fingers correctly". So we need
specific parsing and handling of the situation, and that again requires a
specific use-case.


> I don't see needing to really process firmware strings heavily just compare
> them so the user can be informed that there has been an update/downgrade to
> the firmware and check their interface out. [...]

As said above, the mere knowledge of update/downgrade doesn't hold much
information for what we actually need to do.

> This proactive response stuff is userspace work possible wayland protocol
> work.

fwiw, wayland is a display server protocol. this level of details is beyond its
scope.

> So we need to start with a very limited generic system and expand.   Limited
> being has firmware change yes/no and this triggers events then expand how
> informing to users this is.

We already have this, see e.g.
https://cgit.freedesktop.org/wayland/libinput/tree/udev/libinput-model-quirks.c#n54

So, it all comes down to: unless we know what and why to add this, we don't
know what to do given the rather generic issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

oia...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|MOVED   |---

--- Comment #3 from oia...@gmail.com ---
https://en.wikipedia.org/wiki/System_Management_BIOS

Peter Hutterer thing are changing.   I left it open on the term Firmware.   I
class DMI as part of Firmware that need to be checked.

At a min I think libinput should store and check the SMBIOS/DMI inform to check
the bios/UEFI on a x86 system.As this is one thing that EFI standard is
pushing that OS like Windows will update.

If this does not have a place in libinput it need a home somewhere.

The issue is UEFI with OS update deployed updates to UEFI means that the reason
why X input device/output device could stop working is that the core boot up
firmware has changed.

--The FW version is afaict a free-form string--
I don't see where it being a free-form string is a problem.   If I am using the
same firmware as I was using last time the firmware version strings should
remain identical right.  I don't know of firmware version strings changing
random-ally on anything other than broken hardware.   This is so user knows
that the Firmware their devices are using have change.   It does not matter if
the firmware has changed to older to newer its that the end user knows they are
sitting on change firmware and if there is a problem they can go and find out
how to exactly id the firmware versions they have and had.  

I don't see needing to really process firmware strings heavily just compare
them so the user can be informed that there has been an update/downgrade to the
firmware and check their interface out.   Like the system could ask if user
wishes to-do calibration(diagnostic) run due to firmware change hopefully to
detect issues sooner or enable all form if input systems in a fail safe mode
like on screen keyboards until users interface is confirmed as still working
due to the fact the machine has changed.

This is what I am talking about allowing proactive informing of users and
proactive responses by users to check for errors so they are not half way
though something and find a key pen or item does not work and having no clue
when it last worked.   Also if libinput has a diagnostic connect to this there
could be options to disengage work around after a firmware change and report if
they are fixed. 

This proactive response stuff is userspace work possible wayland protocol work.

You have to remember this is a chicken and egg problem.  For kernel drivers to
export firmware information as standard data format there need to be something
userspace wishing to consume it and use it otherwise they will keep on
exporting in vendor unique formats.

Down the track having kernel export firmware version information better would
require working with driver developers.   But checking and reporting users
about firmware changes has start somewhere.   Linux kernel already exports
enough firmware string information to start this feature DMI would be a
starting point.  I am not expecting a feature like this to be completed quickly
or be perfect.  Being present as a feature to start working out of the check
and egg problem of firmware version strings..

Remember a computer could go its complete operational life without a firmware
update to anything yet another computer could have had 8 updates in a year.

Really there need to generic system to connect up reporting of firmware change
allowing the user space to respond inform user to detect firmware caused issues
early.

Starting case by case and hoping for a generic system for this to appear is
going to create the same vendor unique version stringing problem if not
insanely careful that we already have.

So we need to start with a very limited generic system and expand.   Limited
being has firmware change yes/no and this triggers events then expand how
informing to users this is.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

Peter Hutterer  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #2 from Peter Hutterer  ---
I'm gonna close this for now. This bug is an RFE that's a bit too generic. As I
pointed out in Comment 1, "the firmware" is a bit ambiguous since it depends on
device type, what protocol we're using, etc. This seems to be a case where we
have to figure it out one by one for a couple of specific use-cases and then
take a step back to find a more generic solution. Meanwhile, having this bug
open doesn't really do anything other than clutter up my lists :)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

Peter Hutterer  changed:

   What|Removed |Added

 CC||benjamin.tissoi...@gmail.co
   ||m, peter.hutte...@who-t.net

--- Comment #1 from Peter Hutterer  ---
This is something that needs to be discussed on the kernel side, but either way
it's going to be... tricky. The FW version is afaict a free-form string, so
we'd still need a lot of guesswork in libinput either way.

The simple approach would be another ioctl like e.g. EVIOCGUNIQ but I'm not
sure "the firmware" is precise enough since we still need to sometimes match on
DMI as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 97912] Feature Request: Support for Firmware Version Detection.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97912

Bug ID: 97912
   Summary: Feature Request: Support for Firmware Version
Detection.
   Product: Wayland
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: libinput
  Assignee: wayland-bugs@lists.freedesktop.org
  Reporter: oia...@gmail.com

I know from the XDC2016 conference at this stage the Linux Kernel at minimum
does not provide framework to get the firmware versions of the devices in use.

Going forwards this is going to be a issue.Windows 10 has automatic update
that have been ruining people days.   So someone running Linux fires up windows
returns to Linux now mouse/keyboard could now have a major glitch.

Even under Linux with UEFI there is work to allow Linux systems to be install
firmware updates for that.

Current method dealing with firmware changes is basically wack-a-mole.

For proactive dealing with firmware changes framework to get what firmware
version the devices libinput and possible other sections are interface with.  
Then a framework to compare what was the pass working configuration and what is
the systems current configuration so that user can be informed if some firmware
has change and what device it is.   This would allow users to take a proactive
response to a firmware change not wait until they happen to use it at random. 

Now if some hardware has a workaround and the firmware version has changed and
libinput can detect it there is a possibility for something interface to offer
the user the option to turn the workaround off to see if it still required or
not.

How intelligently libinput can handle firmware change is limited by the missing
feature to in fact find out about firmware version so system can detect change.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs