Re: [PATCH v2 2/2] Input: atkbd - Fix TUXEDO NB02 notebook keyboards FN-keys

[Werner Sembach <wse@tuxedocomputers.com>]

Hi Hans,

Am 05.03.25 um 15:18 schrieb Hans de Goede:
> Hi Werner,
>
> On 5-Mar-25 1:07 PM, Werner Sembach wrote:
>> Am 05.03.25 um 12:25 schrieb Hans de Goede:
>>> Hi Werner,
>>>
>>> On 3-Mar-25 8:04 PM, Werner Sembach wrote:
>>>> This small driver does 2 things:
>>>>
>>>> It remaps the touchpad toggle key from Control + Super + Hangaku/Zenkaku to
>>>> F21 to conform with established userspace defaults. Note that the
>>>> Hangaku/Zenkaku scancode used here is usually unused, with real
>>>> Hangaku/Zenkaku keys using the tilde scancode.
>>> So this control + super + scancode 0x76 sending is also seen on
>>> quite a few other laptops and I think we need a generic fix for this.
>>>
>>> I recently noticed that KDE's keyboard-shortcut settings actually has
>>> a  control + super + Hangaku/Zenkaku -> touchpad-toggle key binding
>>> in its default bindings (IIRC). But that cannot work because xkb actually
>>> has no mapping for evdev code 85 / KEY_ZENKAKUHANKAKU if you look in:
>>>
>>> /usr/share/X11/xkb/keycodes/evdev and then look for 93 (*) you will
>>> find no mapping. I think this KDE default binding may be from a long
>>> time ago when this did work. Or maybe KDE uses the FOO part of KEY_FOO
>>> as symbolic when there is no xkb mapping ?
>> It does not work on X11, but it does work on Wayland (there xev also sees the Zenkaku/Hankaku keypress). Don't ask me why.
> Interesting, so in xev under Wayland you see something like this
> on release:
>
>      state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
>
> With there actually being a keysym of "Zenkaku_Hankaku" there ?
>
> Because that is not working on Wayland on my laptop with the same
> issue (after disabling the hwdb mapping) and I don't understand
> how that could work at all given that /usr/share/X11/xkb/keycodes/evdev
> has no mapping for EV keycode 85 (93 in that file) ?
>
>> Also: Other DEs don't have this binding.
> Yes that is an issue, but see below.
>
>>> *) 85 + 8 all codes there are shifted up 8 compared to the KEY_FOO
>>> defines because codes 0-7 are reserved for modifier.
>>>
>>> I hit the same issue years ago on "T-boa Tbook air" laptop and
>>> their I fixed this by mapping Hangaku/Zenkaku -> f21 in
>>> /lib/udev/hwdb.d/60-keyboard.hwdb :
>>>
>>> ###########################################################
>>> # T-bao
>>> ###########################################################
>>>
>>> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnT-bao:pnTbookair:*
>>>    KEYBOARD_KEY_76=f21                                    # Touchpad toggle
>>>
>>> + teaching GNOME to also accept Ctrl + Super + XF86TouchpadToggle
>>> as touchpad-toggle:
>>>
>>> https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/blob/master/data/org.gnome.settings-daemon.plugins.media-keys.gschema.xml.in?ref_type=heads#L577
>> Yeah KDE would need a similar fix and other DEs probably too. I hoped for a generic fix that does not need adjustments in so many projects.
>>
>> My first try was to do it on the XKB level but on Wayland the RedirectKey action is not implemented https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/794#note_2803713 (and probably wont be even in the future https://github.com/xkbcommon/libxkbcommon/issues/18#issuecomment-72728366) so I can't "unpress" control and super.
>>
>> If it is a more general issue, why not fix it on a more general level in the kernel? Maybe a generic filter applyable via a command line quirk and/or a quirk list?
> The problem is that filtering keys with modifiers like you are doing
> here just does not work.
>
> Your filter is seriously messing with the timing of the keypresses
> which can be a real issue when not actually using the toggle touchpad
> hotkey.
>
> Lets say the user is playing a game and has mapped super to
> one of the fire buttons and is using an in game weapon with
> some sort of auto-repeat firing.
>
> And your seqpos variable likely is 0 when super gets pressed,
> now the keyboard sends 0xe0, 0x5b which your filter filters
> out, and the user keeps super pressed because they expect
> the weapon to start firing on auto-repeat. But the super
> press is never send until super is released or another key
> is pressed so things don't work.
>
> Likewise if the DE, an app or accessibility settings want to
> differentiate between a short and a long super press all
> presses now become super (pun not intended) short because
> you insert the press directly in front of the release, losing
> any timing information about how long the key was pressed.
>
> This is why using an i8042 filter for filtering key-combinations
> (and the EC emulates a key-combination here) can never work reliably.

I just had an idea how this filter could work without running into these issues:

Still listen to the whole key sequence and just suppress the 0x76 and 0xf6. Then 
after the sequence has finished issue a F21 keypress.

Would this fly?

Best regards,

Werner

>
> OTOH desktop environments already allow having Ctrl+Super+something
> keybindings for DE actions. So we can re-use the tried and trusted
> modifier handling in the DE to deal with combi part leaving just
> the issue of mapping PS/2 scancode 0x76 aka evdev code
> 85 / KEY_ZENKAKUHANKAKU to something usable by the DE.
>
> ATM both GNOME and KDE already have support for
> Ctrl+Super+something for touchpad-toggle except that KDE expects
> a "Zenkaku_Hankaku" keysym where as GNOME expects "XF86TouchpadToggle"
> arguably the GNOME solution is slightly better because Japanese
> keyboard layouts already use/send the "Zenkaku_Hankaku" keysym
> unrelated to touchpad-toggle use. And I don't know what happens
> when pressing ctrl+super+Zenkaku_Hankaku while using a Japanese
> layout.
>
> I think maybe we just need to patch atkbd.c at the kernel to
> map scancode 0x76 -> KEY_TOUCHPAD_TOGGLE since normal PS/2
> keyboards never generate 0x76, this would lose the mapping to
> KEY_ZENKAKUHANKAKU but since /usr/share/X11/xkb/keycodes/evdev
> does not even map KEY_ZENKAKUHANKAKU I don't think loosing that
> mapping will do a big deal.
>
> So I think that going with the evdev mapping + teaching KDE
> that Ctrl+Super+XF86TouchpadToggle is just XF86TouchpadToggle
> is the best way forward to solve this once and for all.
>
>>>> It suppresses the reserved scancode produced by pressing the FN-key on its
>>>> own, which fixes a warning spamming the dmesg log otherwise.
>>> Can you not also suppress this by mapping the key to "unknown" in hwdb?
>> Maybe, I didn't try. Was convenient to just do it here since I already had the filter. Will look into it once it is decided what to do with the touchpad toggle issue.
> Please give using hwdb for this a try.
>
> Regards,
>
> Hans
>
>