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

[Carlos Garnacho]

Hey :),

On Mon, Feb 16, 2015 at 4:50 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> ok, I've played around with the ideas in this thread and discussed it with
> Benjamin this morning. Short summary: I think we should go with the original
> patch, with an optional extension for numbered axes later.
>
> I tried the enum spacing first, providing an API where  we have
>    LIBINPUT_BUTTONSET_AXIS_TYPE_COUNT = 512
>    LIBINPUT_BUTTONSET_AXIS_RING = 512
>    LIBINPUT_BUTTONSET_AXIS_STRIP = 1024
>
> so the caller can use code like
>    libinput_event_buttonset_get_axis_value(event,
>                                    LIBINPUT_BUTTONSET_AXIS_RING + 2);
> to get the third axis. switching event-debug showed the issues with this
> approach: to effectively go through the axes, the client needs two loops,
> one for the type one for the number and mask the enum into a type and a
> number component, something that's prone to bugs.
>
> Next attempt was to split value and axis number explicitly in the API:
>    libinput_event_buttonset_get_axis_value(event,
>                                            LIBINPUT_BUTTONSET_AXIS_RING,
>                                            2);
> Better than the above as it's less error-prone.
> It still doesn't remove the above issue though, nested loops everywhere to
> access the type and the number.
> event-debug is a special case in that it doesn't care about the content and
> cares more about listing/printing everything. However I suspect that any
> generic toolkit will require the same.
>
> [Internally both changes are a bit of a nightmare as both would require some
> rewriting, but that's solveable]
>
> So the question is now: what does this gain us? better handling of truly
> generic devices with random axes. Which leads into the next question: what
> are random axes?
> The above approach is over-engineered because there's a group of axes
> that only exists once. I don't think there's a device with two X axes on the
> same device for example. Likewise, there are axes that have more use being
> semantically labelled than just numbered. The ring axes are a good example,
> the current RING and RING2 naming is bad, we should name it RING_LEFT,
> RING_RIGHT instead.

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.

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.

Cheers,
  Carlos