Hi, On 1/16/24 20:05, Dmitry Torokhov wrote: > On Tue, Jan 16, 2024 at 03:43:10PM +0100, Hans de Goede wrote: >> Hi, >> >> On 1/16/24 14:32, Barnabás Pőcze wrote: >>> >>> After: >>> >>> evdev:input:b0011v0001p0001* >>> KEYBOARD_KEY_f8=fn >>> KEYBOARD_KEY_76=f21 >>> >>> I: Bus=0011 Vendor=0001 Product=0001 Version=abba >>> N: Name="AT Translated Set 2 keyboard" >>> P: Phys=isa0060/serio0/input0 >>> S: Sysfs=/devices/platform/i8042/serio0/input/input4 >> >> I see, thank you. There are no v0001p0001 matches >> in the hwdb.d/60-keyboard.hwdb shipped with systems. >> >> Typically laptop builtin keyboards use another match-type >> so that they can do DMI matching e.g.: >> >> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn*:* >> >> So luckily for almost all users the e field in the match >> rule changing should not be an issue. Sorry that this >> was a problem for you. > > Hans, I wonder, if we skip "GET ID" command because it is a > portable/laptop, maybe we should assume that it is the standard "0xab83" > instead of "0xabba" that we assign if GET ID fails but SET LEDS > succeeds. What do you think? That sounds like a good idea to me. I was already wondering if there was a standard response. Do you plan to write a fix yourself or shall I propose one ? Regards, Hans
