Bug 1196586 - udev keyboard scancode remap via hwdb stopped working
udev keyboard scancode remap via hwdb stopped working
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
x86-64 openSUSE Tumbleweed
: P5 - None : Normal (vote)
: ---
Assigned To: Jiri Kosina
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2022-03-01 08:57 UTC by Matthias Welwarsky
Modified: 2022-03-02 09:11 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Welwarsky 2022-03-01 08:57:08 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:*
Comment 1 Matthias Welwarsky 2022-03-01 09:09:54 UTC
Additional info:

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.
Comment 2 Takashi Iwai 2022-03-01 09:26:50 UTC
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?
Comment 3 Matthias Welwarsky 2022-03-01 13:30:32 UTC
Your kernel: 5.16.11-1.g84d014f-default

fixes the problem. Thanks.
Comment 4 Takashi Iwai 2022-03-01 13:53:16 UTC
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?
Comment 5 Matthias Welwarsky 2022-03-01 19:11:09 UTC
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.
Comment 6 Matthias Welwarsky 2022-03-02 09:04:17 UTC
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.
Comment 7 Takashi Iwai 2022-03-02 09:11:29 UTC
Thanks for the information, happy to close now :)