Bug 97912

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.

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 :)

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.

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.

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 detection and logging be done so that strange events are diagnosable even if the fault does not lead back to libinput.   If libinput logged strange hardware information and it now looks like prior hardware information now I know that I need to run memory/drive checks as this is most likely bad drive or bad memory that may or may not be detected by the kernel.

This is why I say hardware compare might be better placed out side libinput.  Even so libinput correctly logging what it detected would be useful diagnostic tool when strange thing have happen that is not in my toolbox.   Its important so that when user says they had X problem and I turn up and X problem no longer there so I have somewhere to look to see if a cause existed.   What is produced has to be sane to read.

--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 this is true it is like saying cars don't need airbags because crashes don't happen often. 

Even that a input device has been plugged into a different port can be useful to us doing hardware diagnostics why 1 port might be suspect and every device plugged into that port malfunctions.   You can fairly much guess how this happens someone unplug a mouse to plug a drawing tablet in and then plugs mouse back into a different port.

Input devices is something users have habit of playing and changing lot more commonly than most other things other than storage devices.  Input devices effect user experience a lot.

Peter Hutterer think about it with the device information libinput current logs by default would you like to be me attempting to diagnose what the user/windows 10 has done for it to break.   Some of the machines I deal with are 10+ years old and lot of port wear.

Not giving nice clean information over input devices firmware location and other things is not a new problem.  But it is a problem I wish would disappear in the process of going to wayland.

(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 this is true it is like saying cars don't need airbags
> because crashes don't happen often. 

sorry, that's a bad analogy. if you want a car analogy, it'd be more like:
we should make sure the driver can read the serial number of every part of
the car so they have something to compare in case the car misbehaves. bad
analogy too, but a bit closer :)

> Not giving nice clean information over input devices firmware location and
> other things is not a new problem.  But it is a problem I wish would
> disappear in the process of going to wayland.

this has nothing to do with wayland (remember, we're using libinput on X
too). As I said above, you're welcome to have a go at the firmware
detection, there are plenty of storage mechanisms available for outside
clients. You could either hook it up to udev or even provide a dbus daemon
that provides the information on request. If you come up with something
useful, we can use it from libinput. But honestly, with this bug as is now I
wouldn't even know where to start.

So I'm closing this bug again, please leave it closed this time. I repeat a summary: there is a legitimate case for knowing firmware versions of the various bits that make up the input stack. But there is lack of support from the kernel drivers and the version to export or read is not always clear, so simply having the number would be insufficient.

Reading the various firmware versions is outside of libinput's scope and better suited for an external project. Once they are available in some reliable manner, we can look at how to use it from within libinput, but for now, this bug is too much blue sky for libinput to consider.