Contextual/Adaptive Bindings

[X9VoiD]

As outlined in this comment, the effect of a binding should stay true to its name. Many users are confused when they realize that most pointer-related bindings are not actually compatible to other output modes. #2505 solves it in Linux by mapping pen tip and buttons event to mouse clicks. However, we do not want this behavior.

Labeling both as a "mouse binding" is not right as it would cause confusion later on when a pen tip or button event is handled differently from an actual mouse click/button event.

What I propose instead is to have a set of "defaults of the defaults" binding that works whatever output mode is chosen, with the output mode's chosen function of the binding, without stating what the binding is for exactly.

• Adaptive pen tip
• Adaptive pen button 1
• Adaptive pen button 2
• Adaptive pen eraser tip

The underlying binding that these adaptive bindings invoke should also be exposed where supported.

Adaptive	Windows Ink	Linux Artist Mode	Absolute Mode / Relative Mode
Adaptive: Pen tip	Windows Ink: Pen tip	Linux Artist Mode: Pen tip	Mouse: Left click
Adaptive: Pen button 1	Windows Ink: Pen button 1	Linux Artist Mode: Pen button 1	Mouse: Right click
Adaptive: Pen button 2	Windows Ink: Pen button 2	Linux Artist Mode: Pen button 2	Mouse: Middle click
Adaptive: Pen eraser tip	n/a (automatically handled)	n/a (automatically handled)	n/a

This would give the user explicit control whether they want an adaptive binding that "just works" for any setup, or if they want a specific function from a specific output mode. In the future we may make use of the information that the binding is used on a foreign output mode to "spawn" the correct one and use it so the binding will still work well.

IMouseButtonHandler can be used as a base to implement the adaptive bindings.

[gonX]

We likely want these virtual endpoints to always be created when such bindings are present, to enable the widest possible functionality. I believe you hinted at this in a Discord conversation the other day.

This would enable 100% mouse functionality in Artist Mode, as the current issue is that tablet endpoints (which Artist Mode is) cannot send events that are not allowed by that type of device, despite telling libinput/evdev that we will send these events IIRC, they are even represented as being keys we can send when asking the endpoint with evtest etc, but it seems they are just silently dropped somewhere in the stack.

Currently, not having actual mouse buttons in artist mode is one of the few remaining roadblocks for eliminating absolute mode entirely.