On Tue, Jan 16, 2024 at 08:33:39PM +0100, Hans de Goede wrote: > 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 ? Please propose a patch. Thanks. -- Dmitry
