[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

--- Comment #5 from oiaohm at 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 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.

-- 
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/a0b5fc35/attachment.html>