[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fe3b171-afc0-47de-802c-28470ce40674@redhat.com>
Date: Wed, 10 Apr 2024 14:32:56 +1000
From: Peter Hutterer <peter.hutterer@...hat.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Mark Pearson <mpearson-lenovo@...ebb.ca>, hdegoede@...hat.com,
ilpo.jarvinen@...ux.intel.com, hmh@....eng.br,
ibm-acpi-devel@...ts.sourceforge.net, platform-driver-x86@...r.kernel.org,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
njoshi1@...ovo.com, vsankar@...ovo.com
Subject: Re: [PATCH 1/4] Input: Add trackpoint doubletap and system debug info
keycodes
On 10/04/2024 11:20, Dmitry Torokhov wrote:
> On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote:
>> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote:
>>> On 09/04/2024 09:31, Dmitry Torokhov wrote:
>>>> Hi Mark,
>>>>
>>>> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote:
>>>>> Add support for new input events on Lenovo laptops that need exporting to
>>>>> user space.
>>>>>
>>>>> Lenovo trackpoints are adding the ability to generate a doubletap event.
>>>>> Add a new keycode to allow this to be used by userspace.
>>>>
>>>> What is the intended meaning of this keycode? How does it differ from
>>>> the driver sending BTN_LEFT press/release twice?
>>>>>
>>>>> Lenovo support is using FN+N with Windows to collect needed details for
>>>>> support cases. Add a keycode so that we'll be able to provide similar
>>>>> support on Linux.
>>>>
>>>> Is there a userspace consumer for this?
>>>
>>> Funnily enough XKB has had a keysym for this for decades but it's not
>>> hooked up anywhere due to the way it's pointer keys accessibility
>>> feature was implemented. Theory is that most of userspace just needs
>>> to patch the various pieces together for the new evdev code + keysym,
>>> it's not really any different to handling a volume key (except this
>>> one needs to be assignable).
>>
>> What is the keysym? If we can make them relatable to each other that
>> would be good. Or maybe we could find a matching usage from HID usage
>> tables...
There's a set of XK_Pointer_ keysyms defined in X11/keysym.h, including XK_Pointer_DblClick1 and XK_Pointer_DblClickDefault.
Unfortunately they're not hooked up to anything atm, see this draft MR:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/659
Because they're not hooked up anywhere they'll also need to be hooked into the client space, same as the various XF86FooBar symbols we've added over the years.
If we were to add KEY_DOUBLECLICK we can patch xkeyboard-config to bind that to the existing XK_Pointer_DblClickDefault symbol (it would get XF86DoubleClick assigned by the current automated scripts), so in theory that key would work like any other key with that symbol assigned.
> I was looking through the existing codes and I see:
>
> #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */
>
> We also have KEY_VENDOR used in a few drivers/plafrom/x86, including
> thinkkpad_acpi.c and I wonder if it would be suitable for this vendor
> specific debug info collection application (which I honestly doubt will
> materialize).
fwiw, I suggested KEY_DOUBLECLICK because that is the action the user takes. Whether that starts a particular application is mostly a question of configuration, defaulting to something that emulates a double-click seems prudent though. And if someone wants to remap that to the compose key that'd be trivial too then.
Cheers,
Peter
Powered by blists - more mailing lists