Bugzilla – Bug 1196586
udev keyboard scancode remap via hwdb stopped working
Last modified: 2022-03-02 09:11:29 UTC
After snapshot 20220225 (kernel 5.6.10-1-default) remapping keyboard scancodes to keys through hwdb override has stopped working. 20220225 is still ok, 20220227 with kernel 5.6.11-1-default is broken.
I straced systemd-udevd to see if the EVIOSCKEYCODE ioctl was actually applied, it returns with '0'.
8521 ioctl(6, EVIOCSKEYCODE, [458805, KEY_102ND] <unfinished ...>
8521 <... ioctl resumed>) = 0
8521 ioctl(6, EVIOCSKEYCODE, [458852, KEY_GRAVE] <unfinished ...>
8521 <... ioctl resumed>) = 0
This is the hwdb override file:
$ cat /etc/udev/hwdb.d/70-keyboard.hwdb
evdev:name:Apple Inc. Apple Internal Keyboard / Trackpad:*
locking kernel version to 5.6.10-1 in Yast and then upgrading to 20220227 results in a working system. So it's in fact some change in the kernel package that broke the functionality.
Through a quick glance, there is a patch for HID apple in 5.16.11, and it might be the cause.
I'm building a test kernel with the revert of the patch. It's being built in OBS home:tiwai:bsc1196586 repo. Once after the build finishes (takes an hour or so), could you give it a try later?
Your kernel: 5.16.11-1.g84d014f-default
fixes the problem. Thanks.
OK, then it's indeed a regression by the upstream commit e26a78057c25dd56f112d536319c38735ed92ba4
HID: apple: Set the tilde quirk flag on the Wellspring 5 and later
Jiri, could you handle this for upstream at first?
Thanks. For information - the machine that shows the regression is a mid-2012 MacBook Air (5,2). Reading up on the patch comments on lkml, it's probably not a regression with EVIOCSKEYCODE as such but with the quirk handling in general that takes priority over any scancode remapping for the keys that are affected by the particular quirk.
The patch seems to have enabled the TILDE quirk handling on my machine and even though a scancode remapping took place, the quirk handling had the priority.
I generally frown on "policy" baked into kernel drivers. Keycode fixups are better handled in userspace. None of this should be in the kernel.
Also, the VID:PID matching seems overly broad. On my machine, the keyboard is 05ac:024d. It does not have the TILDE quirk, but is has a different one: the keys for ^° and <>| are swapped, which is super annoying but easily fixed with a custom hwdb override and no necessity for a kernel patch - if the driver doesn't get in the way.
So, I dug a bit into the hid_apple driver source code. I'm not entirely sure what happened in my case, however, I think this report can be closed. There is not actually a regression but some other effect that I have not yet fully understood.
The "TILDE" quirk _does_ actually affect my machine. I just wasn't aware of it because I didn't understood what the quirk handling does until I read the source code: It swaps KEY_GRAVE and KEY_102ND, which is exactly what my hwdb override does.
So, instead of a hwdb patch I could have added "iso_layout=1" to the module params and it would have solved my problem as well.
Now, I haven't fully understood what interaction there was with my hwdb override. It seems like it was applied, but what it did was in fact revert the effect of the quirk handling, which is why I perceived this as a regression.
I'd mark this as "resolved", no further action required.
Thanks for the information, happy to close now :)