From: "Marek Behún" <kabel@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
linux-input@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v2 6/7] HID: lenovo: Map mic-mute button to KEY_F20 instead of KEY_MICMUTE
Date: Sun, 21 Feb 2021 12:37:22 +0100 [thread overview]
Message-ID: <20210221123722.5446fc13@kernel.org> (raw)
In-Reply-To: <5bda52b5-0f6e-8bce-e53c-108081da87ee@redhat.com>
On Sun, 21 Feb 2021 11:42:16 +0100
Hans de Goede <hdegoede@redhat.com> 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@redhat.com> 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.
next prev parent reply other threads:[~2021-02-21 11:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-20 12:24 [PATCH v2 0/7] HID: lenovo: Mute LED handling fixes and improvements Hans de Goede
2021-02-20 12:24 ` [PATCH v2 1/7] HID: lenovo: Use brightness_set_blocking callback for setting LEDs brightness Hans de Goede
2021-02-21 1:26 ` Marek Behún
2021-02-23 8:59 ` Pavel Machek
2021-02-20 12:24 ` [PATCH v2 2/7] HID: lenovo: Fix lenovo_led_set_tp10ubkbd() error handling Hans de Goede
2021-02-21 1:37 ` Marek Behún
2021-02-20 12:24 ` [PATCH v2 3/7] HID: lenovo: Check hid_get_drvdata() returns non NULL in lenovo_event() Hans de Goede
2021-02-21 1:39 ` Marek Behún
2021-02-20 12:24 ` [PATCH v2 4/7] HID: lenovo: Remove lenovo_led_brightness_get() Hans de Goede
2021-02-21 1:39 ` Marek Behún
2021-02-20 12:24 ` [PATCH v2 5/7] HID: lenovo: Set LEDs max_brightness value Hans de Goede
2021-02-20 15:16 ` Marek Behun
2021-02-20 16:34 ` Hans de Goede
2021-02-20 16:47 ` Marek Behun
2021-02-20 12:24 ` [PATCH v2 6/7] HID: lenovo: Map mic-mute button to KEY_F20 instead of KEY_MICMUTE Hans de Goede
2021-02-21 1:42 ` Marek Behun
2021-02-21 10:42 ` Hans de Goede
2021-02-21 11:37 ` Marek Behún [this message]
2021-02-21 11:50 ` Hans de Goede
2021-02-20 12:24 ` [PATCH v2 7/7] HID: lenovo: Set default_trigger-s for the mute and micmute LEDs Hans de Goede
2021-02-21 1:43 ` Marek Behun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210221123722.5446fc13@kernel.org \
--to=kabel@kernel.org \
--cc=benjamin.tissoires@redhat.com \
--cc=hdegoede@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).