Hi Dmitry On Tue, Apr 9, 2024, at 9:20 PM, 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... > > 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). > That's a somewhat disappointing note on your doubts, is that based on anything? Just wondering what we've done to deserve that criticism. That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I personally don't think KEY_CONFIG matches well), but I would be worried about clashing with existing functionality. Peter - do you have any opinion from the user space side of things, or are these likely unused? KEY_VENDOR seems the safer bet to me (but I don't love it). Dmitry - What are the downsides or concerns of introducing a new code? I'd like to evaluate that against the potential to cause conflicts by re-using existing codes. If you feel strongly about it then I'll defer to your judgement, but I'd like to understand better the context. Thanks Mark
