Hi, On 2/21/21 12:37 PM, Marek Behún wrote: > 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 :( Many people have looked into fixing this, but X11 is a network protocol, and the other side could be a many many years old X-terminal (one of those devices which don't have their own OS but connect over xdmcp to show a desktop running on some big machine somewhere else on the LAN). XKB in X is layered on top of the original X input protocol, and the data gets passed around multiple times in multiple different structs and it is limited to a 8 bit wide int everywhere. Note it is not just micmute. The F13 - F24 F-key range has been used to work around this for a while now. I'm aware of the following "mappings" being used for this: evdev -> interpreted by userspace as KEY_F20 -> mic-mute toggle KEY_F21 -> touchpad on/off toggle KEY_F22 -> touchpad on KEY_F23 -> touchpad off This is not pretty, I know. Regards, Hans
