Received-SPF: pass (google.com: domain of linux-kernel+bounces-137830-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Feedback-ID: ibe194615:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-379-gabd37849b7-fm-20240408.001-gabd37849
Precedence: bulk
MIME-Version: 1.0
Message-Id: <92ee5cb2-565e-413c-b968-81393a9211c4@app.fastmail.com>
In-Reply-To: <ZhXpZe1Gm5e4xP6r@google.com>
References: <mpearson-lenovo@squebb.ca>
 <20240324210817.192033-1-mpearson-lenovo@squebb.ca>
 <20240324210817.192033-2-mpearson-lenovo@squebb.ca>
 <ZhR-WPx7dgKxziMb@google.com>
 <f3342c0b-fb31-4323-aede-7fb02192cf44@redhat.com>
 <ZhW3Wbn4YSGFBgfS@google.com> <ZhXpZe1Gm5e4xP6r@google.com>
Date: Tue, 09 Apr 2024 22:17:05 -0400
From: "Mark Pearson" <mpearson-lenovo@squebb.ca>
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
 "Peter Hutterer" <peter.hutterer@redhat.com>
Cc: "Hans de Goede" <hdegoede@redhat.com>,
 =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>,
 "Henrique de Moraes Holschuh" <hmh@hmh.eng.br>,
 ibm-acpi-devel@lists.sourceforge.net,
 "platform-driver-x86@vger.kernel.org" <platform-driver-x86@vger.kernel.org>,
 linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
 "Nitin Joshi1" <njoshi1@lenovo.com>, "Vishnu Sankar" <vsankar@lenovo.com>
Subject: Re: [PATCH 1/4] Input: Add trackpoint doubletap and system debug info keycodes
Content-Type: text/plain

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