[RFC libinput 1/2] Add a "buttonset" interface for button-only devices

[Carlos Garnacho]

Hey :),

On Thu, Feb 19, 2015 at 2:29 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Wed, Feb 18, 2015 at 11:52:18PM +0100, Carlos Garnacho wrote:
>> I'm not sure left/right specifically is something we want to tell
>> about at this level. With tablet support in mind, I would expect a
>> left-handed mode for buttonsets too, so rings/strips would flip side,
>> be inverted, etc. We can sure flip the axes internally in libinput,
>> but sounds inconsistent if buttons aren't to be actually flipped.
>
> I do intend to flip the buttons, once I figure out how :)
>
>> As for this semantical approach, are we sure the input_event codes
>> won't overlap across different devices that might qualify here? It
>> could be potentially confusing otherwise. TBH I share a bit the
>> concern with Jason here, most probably all apps dealing with this will
>> want their own dialogs and methods to map actions anyway.
>
> The lack of precision in the input_event codes is one reason we have different
> enums for axes in the tablet interface already. we internally discussed
> replacing (or augmenting) the current linux/input.h with libinput specific
> ones but chose that this is not a bridge to cross just yet.
>
> I'm not sure I know what you mean with the overlap problem though, can you
> expand?

I mean, for example the intuos5 ring is advertised as ABS_WHEEL
(meaning RING_LEFT on right-handed mode), picking on the nextbeat
example again (and knowing nothing about it TBH, the example is made
up and extreme), what if such device is partially recognized by
libinput as a buttonset and advertises that axis but it actually means
"treble equalization on track B"? (which by looking to the device
images, isn't neither a ring, nor at the left)

You can catch up reactively to this, and map internally in libinput
the semantical meanings for each axis based on the device, but there's
room for user confusion in the mean time. IMHO, a get_axis_type call
that returns strip/ring/knob/whatnot and admits it's a best effort
guess would allow for some generic treatment above libinput if we
change our guesses over time.

Even if we leak semantic labels all through the protocol, I'm not sure
at which level would these make for better self-explaining code. I
remember from LGM last year, when demoing the GNOME tablet button
mapping, I got quite some "I want to borrow/steal this for $PAINT_APP"
comments. It sounds likely to me that, given the case, they'd just map
the axis number to whatever action, regardless of the enum value name.

Cheers,
  Carlos