[RFC libinput] Import buttonset interface

[PrasannaKumar Muralidharan]

> fwiw, it's very frowned upon to take someone else's patch, rebase it and
> then send it on as your own when it has very little changes. Please keep
> original authorship while it makes sense and add the author as co-author
> where substantial changes have been made.

I definitely did not intend to claim this as my patch. I will set the
correct author when I send the patch again with modifications.

> tbh, I'm not quite sure what to review here though, without a backend
> implementation this is quite theoretical. I'm assuming you just want a
> quick review to make sure nothing obvious got lost in the rebase?
> If so, yes, looks ok, thanks.

Yes. This is one of things I wanted to understand.

> There are a couple of questions that arose from the
> wacom tablet button switch, specifically:
> * what use do the linux/input.h button codes have in the buttonset
>   interface? We will run similar issues with the evdev button code ranges as
>   we did with the pad, where the button code is meaningless.
> * the various axes are nice to have, but without a user I'm hesitant to
>   merge them - we'll need to know how they could be used first

I am dealing is similar to rotary encoder, buttonset interface is the
required for it. I am not aware of the issue mentioned above. I would
prefer to have some guidance on what should be changed or removed. The
main objective of the patch sent is exactly this - I wanted to know
what I have to do to get the buttonset interface merged.

> * ring and strip are absolute, they are wacom-only axes and until we get a
>   device that needs either, we should leave them out.

Will remove them.

> * the seat button count should be removed, it doesn't make sense for a
>   buttonset device
> * get_(x|y)* does not need an axis argument, I struggle to think of a device
>   that has two x or y axes on the same event node.
>
> Other than that I still think that the general approach with numbered axes
> and axis types makes sense.

Okay. Will change accordingly.

>> This change is compile tested.
>
> That's not a confidence-inspiring statement... :)

Agreed. I will follow up with dial input support and will have a
proper working version by then.

Thanks,
PrasannaKumar