[PATCH libinput] Add libinput_device_pointer_has_button over the plain has_button

[Bill Spitzak]

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.