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

[bugzilla-daemon at freedesktop.org]

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

Peter Hutterer <peter.hutterer at who-t.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|REOPENED                    |RESOLVED

--- Comment #6 from Peter Hutterer <peter.hutterer at who-t.net> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170105/2c172641/attachment.html>