Re: [PATCH 1/4] Input: Add trackpoint doubletap and system debug info keycodes

[Dmitry Torokhov]

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.

Thanks.

-- 
Dmitry