[PATCH libinput] Add libinput_device_pointer_has_button over the plain has_button

Peter Hutterer peter.hutterer at who-t.net
Mon Feb 16 17:18:11 PST 2015

On Mon, Feb 16, 2015 at 01:19:38PM -0800, Bill Spitzak wrote:
> On 02/16/2015 01:05 PM, Peter Hutterer wrote:
> >besides, this doesn't really help, you usually want to know if a device has
> >a specific button well before you get the first event. so the real source
> >to use here would be the capability. That could make sense, I'll have a look
> >at this, the API would be something like:
> >
> >libinput_device_has_button(LIBINPUT_DEVICE_CAP_POINTER,
> >                            button);
> Yes that sounds like what I was thinking of.

I had a look at this and I don't think this is a good idea, it makes the API
inconsistent and harder to use.

First, two out of the current five capabilities don't make sense for this
call. keyboard and touch don't have buttons.
This call also doesn't really work for tablet devices, or at least only
inconsistently - on those it's the tool that has the button, not the tablet
The logical extensions of this API are _has_key() and has_axis()
has_key() only makes sense on keyboard and buttonset devices, so a generic
version is worse than a specific one.
has_axis() is even more complicated, we use different enums for axes in the
tablet and buttonset case so again a generic version of this call won't

So I'll stick with the libinput_<type>_has_button approach.


More information about the wayland-devel mailing list