On Tue, Jan 16, 2024 at 08:33:39PM +0100, Hans de Goede wrote:

Hi,

On 1/16/24 20:05, Dmitry Torokhov wrote:

quoted

On Tue, Jan 16, 2024 at 03:43:10PM +0100, Hans de Goede wrote:

quoted

Hi,

On 1/16/24 14:32, Barnabás Pőcze wrote:

quoted

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