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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
