On Sun, 21 Feb 2021 11:42:16 +0100 Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > 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 > And no one ever solved this for X? OMFG :( Very well then.
