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

From: Werner Sembach
Date: Wed Mar 05 2025 - 07:07:33 EST



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.

Also: Other DEs don't have this binding.


*) 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?


Notice that system76 has the same hwdb key mapping for their
Pangolin 12 model which I presume also has something like e.g.
a clevo as base model.

So for now to fix the touchpad on this TUXEDO NB02 you should
simply add a hwdb entry like the above entries.

Longer term I think the right fix for the touchpad toggle for
all laptops which do this would be to make GNOME do what KDE does
and change the touchpad-toggle-static keybinding list which
currently is:

['XF86TouchpadToggle', '<Ctrl><Super>XF86TouchpadToggle']

to:

['XF86TouchpadToggle', '<Ctrl><Super>XF86TouchpadToggle', '<Ctrl><Super>"Something"']

Where "Something" would then be the new mapping. Or maybe just teach
atkbd or xkb or hwdb to map scancode 0x76 to TouchpadToggle by
default then at least in GNOME this will work OOTB and for KDE
a default binding of '<Ctrl><Super>XF86TouchpadToggle'] -> touchpad-toggle
should probably be added there.

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.

Regards,

Hans