Message-ID: <b0d0eac1-76e5-462b-9ff5-605536fa00b4@redhat.com>
Date: Thu, 6 Mar 2025 15:46:58 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Werner Sembach <wse@...edocomputers.com>, mario.limonciello@....com,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: 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

Hi Werner,

On 5-Mar-25 4:41 PM, Werner Sembach wrote:
> 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 ?
> 
> No. Sorry I got it a little bit wrong above, I didn't know it exactly anymore and had to retest:
> 
> 
> With the keyboard shortcut deactivated, xev on wayland shows this:
> 
> KeyPress event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 246681, (83,3), root:(1273,701),
>     state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyPress event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 246682, (83,3), root:(1273,701),
>     state 0x40, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyPress event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 246686, (83,3), root:(1273,701),
>     state 0x44, keycode 93 (keysym 0x0, NoSymbol), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 246690, (83,3), root:(1273,701),
>     state 0x44, keycode 93 (keysym 0x0, NoSymbol), same_screen YES,
>     XLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 246696, (83,3), root:(1273,701),
>     state 0x44, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 246703, (83,3), root:(1273,701),
>     state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> 
> With the shortcut active, xev on wayland shows this (and the shortcut works):
> 
> KeyPress event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 365034, (83,3), root:(1273,701),
>     state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyPress event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 365036, (83,3), root:(1273,701),
>     state 0x40, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XmbLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 365060, (83,3), root:(1273,701),
>     state 0x44, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 39, synthetic NO, window 0x1200001,
>     root 0x4f7, subw 0x0, time 365060, (83,3), root:(1273,701),
>     state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
>     XLookupString gives 0 bytes:
>     XFilterEvent returns: False

Ah ok, so in KDE the shortcut somehow works under Wayland despite
the lack of xkb keysym mapping (maybe match on keycode?) and then 
the compositor absorbs / eats the Zenkaku_Hankaku key-press +
release as it does with other compositor handled hotkeys leaving
apps like xev to just see the modifier press/release events
(which the compositor cannot delay / filter for the same reasons
as why an i8042 kbd filter won't work).

>> 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.
> Ok, thought I had a clean solution, but doesn't seems so xD.

Yeah these single key which the EC makes send a whole key sequence
EC level key-bindings are a pain to deal with. Some for some other
keys emulating Windows hotkey presses like "Super + P", but those
are simply send unmodified to the DE to let the DE deal with them.

Sending these unmodified to the DE pretty much is the only thing
we can do.

>> 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.
> When I interpret the xkb-config correctly, JIS keyboards use the tilde scancode/keycode for the physical zenkaku/hankaku keys, at least in the default config HZTG (henkaku/zankaku toggle) is aliased to TLDE

Yes I don't think the 0x76 ps/2 scancode is used on any actual
keyboards other then for this toggle touchpad key thing.

>> 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.
> 
> At least from kernel side this would be a very small patch, are there any objections to it?

Well it would break the currently working touchpad toggle in KDE,
but the same applies to doing the mapping in hwdb.

I think it would be best to just post the patch + create
a KDE issue and then see from there.

Regards,

Hans

Powered by blists - more mailing lists