Re: [PATCH v2 2/2] Input: atkbd - Correctly map F13 - F24

[Werner Sembach <wse@tuxedocomputers.com>]

Am 18.03.25 um 11:20 schrieb Werner Sembach:
> Hi Hans
>
> Am 17.03.25 um 23:22 schrieb Hans de Goede:
>> Hi,
>>
>> On 17-Mar-25 5:47 PM, Werner Sembach wrote:
>>> Hi again,
>>>
>>> Am 17.03.25 um 13:06 schrieb Hans de Goede:
>>>> Hi,
>>>>
>>>> On 11-Mar-25 19:10, Werner Sembach wrote:
>>>>> Hi Hans, Hi Dimitry,
>>>>>
>>>>> resending this too on the v2 to not cause confusion:
>>>>>
>>>>> Regarding remapping KEY_ZENKAKUHANKAKU to KEY_TOUCHPAD_TOGGLE:
>>>>>
>>>>> Am 11.03.25 um 19:06 schrieb Werner Sembach:
>>>>>> Currently only F23 is correctly mapped for PS/2 keyboards.
>>>>>>
>>>>>> Following to this table:
>>>>>> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf 
>>>>>>
>>>>>>
>>>>>> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world
>>>>>> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch 
>>>>>> binds the
>>>>>> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU 
>>>>>> keycode is
>>>>>> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway.
>>>>> I think what the firmware vendor actually wanted to do was to send 
>>>>> ctrl+super+f24 upon touchpad toggle. This would somewhat fall in line 
>>>>> with, for example, the copilot key being implemented as shift+super+f23.
>>>> I agree that that seems to be the intent.
>>>>
>>>>> Following this, my suggestion is to do this remapping and handle the rest 
>>>>> in xkeyboard-config
>>>> xkeyboard config already contains mappings for F13 - F18 and F20-F23 in
>>>> /usr/share/X11/xkb/symbols/inet
>>>>
>>>> So all that needs to happen there is map FK19 -> F19 and FK24 -> F24.
>>>>
>>>> And then teach KDE + GNOME that ctrl+super+f24 means touchpad-toggle.
>>> Alternative suggestion, again following how the copilot key is implemented:
>>>
>>> key <FK19>   {      [ F19 ]       };
>>> [...]
>>> key <FK23>   {      [ XF86TouchpadOff, XF86Assistant ], type[Group1] = 
>>> "PC_SHIFT_SUPER_LEVEL2" };
>>> key <FK24>   {      [ F24, XF86TouchpadToggle ], type[Group1] = 
>>> "PC_CONTROL_SUPER_LEVEL2" };
>>>
>>> Then only xkb has to be touched again, but not KDE and GNOME.
>> Ah I did not know you could do this. Yes this sounds like a very good
>> plan wrt the xkbconfig changes and then indeed we can do all the handling
>> in xkbconfig.
>>
>>
>>>> We could maybe get away with also dropping the weird mappings for FK13 - FK18
>>>> and map those straight to F13 - F18, but we need the special mappings
>>>> for F20 - F23 to stay in place to not break stuff.
>>> Good question
>>>
>>> XF86Tools launches system settings on KDE.
>> Right, but XF86Tools is also send for KEY_CONFIG which makes more sense,
>> the question is are there any devices actually sending KEY_F13 in
>> a case where they really should be sending KEY_CONFIG instead.
>>
>> Note this is unrelated to the XF86TouchpadToggle thing though, just
>> something which I noticed while looking at things.
>>
>>> Looking at the links in the git log of xkeyboard-config (commit 
>>> 1e94d48801bf8cb75741aa308d4cdfb63b03c66c and 
>>> 01d742bc5cd22543d21edb2101fec6558d4075db) these seems to be device specific 
>>> bindings that got accepted in the default config because the keys where 
>>> unbound before.
>> I see, so it might be worthwhile to try and fix these, but in
>> a separate pull-request from the:
>>
>> key <FK24>   {      [ F24, XF86TouchpadToggle ], type[Group1] = 
>> "PC_CONTROL_SUPER_LEVEL2" };
>
> ack, I will create a MR as soon as the freedesktop gitlab migration is finished.
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/816
>
> Best regards,
>
> Werner
>
>>
>> addition.
>>
>> Regards,
>>
>> Hans
>>
>>