From: Hans de Goede <hdegoede@redhat.com>
To: Mark Pearson <mpearson-lenovo@squebb.ca>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: "Peter Hutterer" <peter.hutterer@redhat.com>,
"Ilpo Järvinen" <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
Date: Tue, 16 Apr 2024 15:03:27 +0200 [thread overview]
Message-ID: <75ed406b-cb96-4e73-a9d6-06cb0332f9bd@redhat.com> (raw)
In-Reply-To: <ce28b0e5-a867-458e-bcb4-cc327be5f19e@app.fastmail.com>
Hi,
On 4/16/24 2:48 PM, Mark Pearson wrote:
> Hi Hans
>
> On Tue, Apr 16, 2024, at 4:33 AM, Hans de Goede wrote:
>> Hi Mark,
>>
>> On 4/16/24 1:57 AM, Mark Pearson wrote:
>>> Hi Dmitry,
>>>
>>> On Mon, Apr 15, 2024, at 6:54 PM, Dmitry Torokhov wrote:
>>>> On Mon, Apr 15, 2024 at 04:28:19PM -0400, Mark Pearson wrote:
>>>>> 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.
>>>>
>>>> Fn+N -> KEY_VENDOR mapping sounds good to me.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> So here is the problem. Keycodes in linux input are not mere
>>>> placeholders for something that will be decided later how it is to be
>>>> used, they are supposed to communicate intent and userspace ideally does
>>>> not need to have any additional knowledge about where the event is
>>>> coming from. A keyboard either internal or external sends KEY_SCREENLOCK
>>>> and the system should lock the screen. It should not be aware that one
>>>> device was a generic USB external keyboard while another had an internal
>>>> sensor that recognized hovering palm making swiping motion to the right
>>>> because a vendor decided to make it. Otherwise you have millions of
>>>> input devices all generating unique codes and you need userspace to
>>>> decide how to interpret data coming from each device individually.
>>>>
>>>> If you truly do not have a defined use case for it you have a couple
>>>> options:
>>>>
>>>> - assign it KEY_RESERVED, ensure your driver allows remapping to an
>>>> arbitrary keycode, let user or distro assign desired keycode to it
>>>>
>>>> - assign KEY_PROG1 .. KEY_PROG4 - pretty much the same - leave it in the
>>>> hand of the user to define a shortcut in their DE to make it useful
>>>>
>>>>>
>>>>> 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?
>>>>
>>>> What would it do exactly? Once we have this answer we can define key or
>>>> button code (although I do agree that game controller buttons are
>>>> different from "normal" keys because they map to the geometry of the
>>>> controller which in turn defines their commonly understood function).
>>>>
>>>> But in any case you would not reuse the same keycode for something that
>>>> is supposed to invoke a configuration utility and also to let's say
>>>> drop a flash grenade in a game.
>>>>
>>>
>>> Understood.
>>>
>>> I don't see a path forward within your stated parameters. I did not realise that there were such limitations, so my apologies for wasting everybody's time, and thank you for your patience and guidance.
>>>
>>> I will drop this patch from the series and proceed using existing defined codes only.
>>>
>>> Hans, I'll need to rejig things a bits but I have some ideas and I think I can make it work and stay within the pdx86 tree, which will make it simpler.
>>
>> Ok this sounds good to me. For Fn + N using KEY_VENDOR sounds good for
>> me and for the doubletap any one of
>> KEY_CONFIG/KEY_CONTROLPANEL/KEY_INFO/KEY_PROG1
>> or some other suitable KEY_foo define works for me.
>>
> I think this should be a configurable input, by design. So my preference (if not allowed a new keycode, which I personally think is the better option) is for PROG1.
>
> I discussed with Peter last night and it looks likely OK on their side. I do plan on doing some testing first, so it might take a few days to get the next set of patches out.
Ok, PROG1 works for me.
Regards,
Hans
next prev parent reply other threads:[~2024-04-16 13:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-24 21:07 [PATCH 0/4] platform/x86,input: Support for new events on Mark Pearson
2024-03-24 21:07 ` [PATCH 1/4] Input: Add trackpoint doubletap and system debug info keycodes Mark Pearson
2024-04-08 12:45 ` Hans de Goede
2024-04-08 23:31 ` Dmitry Torokhov
2024-04-09 0:00 ` Mark Pearson
2024-04-09 10:16 ` Hans de Goede
2024-04-09 21:54 ` Dmitry Torokhov
2024-04-09 5:23 ` Peter Hutterer
2024-04-09 21:47 ` Dmitry Torokhov
2024-04-10 1:20 ` Dmitry Torokhov
2024-04-10 2:17 ` Mark Pearson
2024-04-11 0:02 ` Dmitry Torokhov
2024-04-11 2:48 ` Mark Pearson
2024-04-15 19:40 ` Dmitry Torokhov
2024-04-15 19:50 ` Hans de Goede
2024-04-15 19:58 ` Dmitry Torokhov
2024-04-15 20:28 ` Mark Pearson
2024-04-15 22:54 ` Dmitry Torokhov
2024-04-15 23:57 ` Mark Pearson
2024-04-16 8:33 ` Hans de Goede
2024-04-16 12:48 ` Mark Pearson
2024-04-16 13:03 ` Hans de Goede [this message]
2024-04-16 8:35 ` Hans de Goede
2024-04-11 12:30 ` Hans de Goede
2024-04-15 19:35 ` Dmitry Torokhov
2024-04-15 19:47 ` Hans de Goede
2024-04-15 19:55 ` Dmitry Torokhov
2024-04-10 4:32 ` Peter Hutterer
2024-04-15 19:32 ` Dmitry Torokhov
2024-03-24 21:07 ` [PATCH 2/4] platform/x86: thinkpad_acpi: Support for trackpoint doubletap Mark Pearson
2024-04-08 13:04 ` Hans de Goede
2024-04-08 14:56 ` [ibm-acpi-devel] " Mark Pearson
2024-03-24 21:08 ` [PATCH 3/4] platform/x86: thinkpad_acpi: Support for system debug info hotkey Mark Pearson
2024-04-08 13:11 ` Hans de Goede
2024-04-08 14:56 ` Mark Pearson
2024-03-24 21:08 ` [PATCH 4/4] platform/x86: thinkpad_acpi: Support hotkey to disable trackpoint doubletap Mark Pearson
2024-04-08 13:13 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=75ed406b-cb96-4e73-a9d6-06cb0332f9bd@redhat.com \
--to=hdegoede@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpearson-lenovo@squebb.ca \
--cc=njoshi1@lenovo.com \
--cc=peter.hutterer@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=vsankar@lenovo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).