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

[Peter Hutterer]

On Thu, Feb 19, 2015 at 12:35:52PM +0100, Carlos Garnacho wrote:
> 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.

that's a problem, IMO. once we start labelling an axis we can't easily
change it, it effectively becomes ABI. e.g. once a device has an axis
labelled FOO you can't change this without breaking any application that
relies on exactly that label. which is why I want to avoid an UNKNOWN axis
and rather not support anything we can't identify well.

but it's a tricky problem. on the one hand we have a set of devices
(tablets) that are fairly well-defined and somewhat limited in number, on
the other hand we need the generic support. maybe unifying the two isn't as
useful as we thought?

> 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.

The biggest advantage you get from having libinput know about the device is
the ability to punt e.g. rotation off to libinput and have it auto-rotate
the wheels so you have a well-defined dataset.

Cheers,
   Peter