[PATCH libinput] Add libinput_device_pointer_has_button over the plain has_button

[Peter Hutterer]

On Mon, Feb 16, 2015 at 12:35:13PM -0800, Bill Spitzak wrote:
> 
> 
> On 02/13/2015 07:06 PM, Peter Hutterer wrote:
> >On 14/02/2015 11:17 , Bill Spitzak wrote:
> >>
> >>
> >>On 02/13/2015 04:46 PM, Peter Hutterer wrote:
> >>>On 14/02/2015 05:00 , Bill Spitzak wrote:
> >>>>Actually, more to the point, it sounds like the client is unable to
> >>>>distinguish the BTN_LEFT produced by the pointer from the BTN_LEFT
> >>>>produced by the pad.
> >>>
> >>>the caller can tell what event caused the button.
> >>>
> >>>>If in fact it *can* be distinguished then there should be some very
> >>>>similar api to this "has" function. For instance if there is some
> >>>>sub-device id sent with the events then this function should take that
> >>>>same sub-device id.
> >>>
> >>>what sub-device ID? we don't have subdevices, that was an idea that was
> >>>floated for a while and obsoleted by the device group.
> >>
> >>Sorry for being vague. But what I am saying is that if "the caller can
> >>tell what event caused the button" then something says whether the event
> >>is from the pointer or from the pad. What I am thinking is that this
> >>"has" function should take the same information so that you can ask
> >>whether the pointer or the pad has the button.
> >
> >isn't that exactly what the patch does?
> >
> >Cheers,
> >   Peter
> 
> I think I am not explaining my question correctly.
> 
> There is no "get the next pointer event" api to libinput (unless I am
> seriously mistaken). Instead there is "get the next event". You then peek in
> the event and it has something so the caller can tell whether it is a
> pointer or tablet event. Sorry I don't quite see what that is, but let's for
> the minute assume this is something like "event->source == POINTER".
> 
> It would seem that instead of "have_pointer_button" there should be a call
> called "have_button" that takes this source identifier as another argument.
> Then you can reuse the code to test if it has the same button on the tablet.

the event type is that source, but it's just a number (enum).
libinput_next_event_type() gives you the type without dequeuing the event
but passing that number into the API would be quite awkward.

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);


Cheers,
   Peter