On Wed, Apr 10, 2024 at 02:32:56PM +1000, Peter Hutterer wrote: > 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. I think whether to create and use KEY_DOUBLECLICK is very much depends if we associate this with the pointer somehow, or if we keep it as a completely separate action. If we continue with KEY_DOUBLECLICK then we need to try and define what exactly it means to the applications. Actually same goes if we want another new keycode. As far as easy remapping, I think one can map this to KEY_RESERVED and then remap to whatever they want, you do not need to have a new keycode for that. Thanks. -- Dmitry
