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

["Mark Pearson" <mpearson-lenovo@squebb.ca>]

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.

Mark