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
