Message-ID: <2936f99d-0211-41de-976e-1a5631f62414@tuxedocomputers.com>
Date: Fri, 7 Mar 2025 18:52:54 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Hans de Goede <hdegoede@...hat.com>, mario.limonciello@....com,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: dmitry.torokhov@...il.com, linux-kernel@...r.kernel.org,
 platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v2 2/2] Input: atkbd - Fix TUXEDO NB02 notebook keyboards
 FN-keys


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 ?
>
> *) 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
>
> 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?
Coming back to this: this doesn't work because hwdb handles keycodes, but the 
message in dmesg is produces because the scancode is not mapped to any keycode 
by default (it is mapped to 0 in atkbd.c).
>
> Regards,
>
> Hans
>
>

Powered by blists - more mailing lists