[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <539776c5-6243-464b-99ae-5b1b1fb40e4b@app.fastmail.com>
Date: Mon, 15 Apr 2024 16:28:19 -0400
From: "Mark Pearson" <mpearson-lenovo@...ebb.ca>
To: "Dmitry Torokhov" <dmitry.torokhov@...il.com>,
"Hans de Goede" <hdegoede@...hat.com>
Cc: "Peter Hutterer" <peter.hutterer@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
"Henrique de Moraes Holschuh" <hmh@....eng.br>,
ibm-acpi-devel@...ts.sourceforge.net,
"platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
"Nitin Joshi1" <njoshi1@...ovo.com>, "Vishnu Sankar" <vsankar@...ovo.com>
Subject: Re: [PATCH 1/4] Input: Add trackpoint doubletap and system debug info keycodes
Hi
On Mon, Apr 15, 2024, at 3:58 PM, Dmitry Torokhov wrote:
> On Mon, Apr 15, 2024 at 09:50:37PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/15/24 9:40 PM, Dmitry Torokhov wrote:
>> > On Wed, Apr 10, 2024 at 10:48:10PM -0400, Mark Pearson wrote:
>> >>
>> >> I have a stronger preference to keep the KEY_DOUBLECLICK - that one seems less controversial as a genuine new input event.
>> >
>> > Please see my response to Peter's letter. I think it very much depends
>> > on how it will be used (associated with the pointer or standalone as it
>> > is now).
>> >
>> > For standalone application, recalling your statement that on Win you
>> > have this gesture invoke configuration utility I would argue for
>> > KEY_CONFIG for it.
>>
>> KEY_CONFIG is already generated by Fn + F# on some ThinkPads to launch
>> the GNOME/KDE control center/panel and I believe that at least GNOME
>> comes with a default binding to map KEY_CONFIG to the control-center.
>
> Not KEY_CONTROLPANEL?
>
> Are there devices that use both Fn+# and the doubleclick? Would it be an
> acceptable behavior for the users to have them behave the same?
>
Catching up with the thread, thanks for all the comments.
For FN+N (originally KEY_DEBUG_SYS_INFO) the proposal was to now use KEY_VENDOR there. My conclusion was that this is targeting vendor specific functionality, and that was the closest fit, if a new keycode was not preferred.
For the doubletap (which is a unique input event - not related to the pointer) I would like to keep it as a new unique event.
I think it's most likely use would be for control panel, but I don't think it should be limited to that. I can see it being useful if users are able to reconfigure it to launch something different (browser or music player maybe?), hence it would be best if it did not conflict with an existing keycode function. I also can't confirm it doesn't clash on existing or future systems - it's possible.
FWIW - I wouldn't be surprised with some of the new gaming systems we're seeing (Steamdeck, Legion-Go, etc), that a doubletap event on a joystick might be useful to have, if the HW supports it?
Mark
Powered by blists - more mailing lists