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

[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.

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