Hi, On 2/21/21 2:42 AM, Marek Behun wrote: > On Sat, 20 Feb 2021 13:24:37 +0100 > Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >> Mapping the mic-mute button to KEY_MICMUTE is technically correct but >> KEY_MICMUTE translates to a scancode of 256 (248 + 8) under X, >> which does not fit in 8 bits, so it does not work. > > Why does it need to fit 8 bits? Where is the problem? As the commit message says, "under X" aka X11 / Xorg. This is a well known limitation of the X11 input stack / of XKB *as implemented in X11* the Wayland input stack does not have this limitations and does allow using raw key-codes >= 248. If you look at e.g. : https://github.com/systemd/systemd/blob/main/hwdb.d/60-keyboard.hwdb Which (mostly) maps custom PS/2 scancodes used for some "media" keys on laptops to linux evdev KEY_FOO codes, then you will see that there are no lines there which end with "=micmute" instead there are quite a few lines like this: KEYBOARD_KEY_8a=f20 # Microphone mute button; should be micmute Arguably it would be more correct to have the kernel still send KEY_MICMUTE and do the remapping to KEY_F20 in userspace in e.g. hwdb. But that will not work here, the remapping is done based on mapping the HID usage-code to a new evdev KEY_FOO code, basically overriding lenovo_input_mapping_tp10_ultrabook_kbd() mapping. But the "Lenovo ThinkPad 10 Ultrabook Keyboard" uses the same 0x000c0001 usage code for all of its custom Fn+F# media keys, so instead of doing the mapping purely on usage-code it is done on a combination of usage-code + the index of the key in the input-report (since the usage-code is not unique for a single key): /* * The ThinkPad 10 Ultrabook Keyboard uses 0x000c0001 usage for * a bunch of keys which have no standard consumer page code. */ if (usage->hid == 0x000c0001) { switch (usage->usage_index) { case 8: /* Fn-Esc: Fn-lock toggle */ map_key_clear(KEY_FN_ESC); return 1; case 9: /* Fn-F4: Mic mute */ map_key_clear(LENOVO_KEY_MICMUTE); return 1; ... So in this case we cannot fixup the mapping from userspace, as userspace remapping is purely done based on the "scancode" which in case of HID devices is the HID usage-code. I don't even know what will happen if we were to try. I guess that either the first key with a matching usage-code is remapped, or all of them are remapped, both of which are wrong. Regards, Hans
