If it's a finger, it's a touchscreen or a touchpad, not a tablet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
By definition, the state is always proximity in on other events but let's
allow the call to be made anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
At least on the t440, this is enough to trigger correct detection between
pinch and scroll 90% of the time. Since scrolling is significantly more
prevalent than gesturing, erring on the side of scrolling at the cost of
misdetecting some gestures is acceptable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Behavior for axis events in the same event frame as the BTN_TOUCH is to
always send axis events before any tip state.
Behavior for button events in the same event frame as the BTN_TOUCH is to
order button events to happen when the tip is in proximity, i.e. after the tip
event on tip down and before the tip event on tip up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The tablet tip works like a button in the kernel but is otherwise not really
a button. Split it into an explicit tip up/down event instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We send the axis state in the proximity event so we don't send another axis
event for the same state. The first axis event is sent whenever the tool
moves. This is largely of note for test cases, in real-world usage a tool
cannot be held still enough to never send axis updates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Otherwise events that are already queued before the first libinput_dispatch()
have a negative timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There were two files (doc/svg/{edge,twofinger}-scrolling.svg) that had both
arrow heads pointing to wrong direction. Those arrow heads used markers but
their ids were defined wrong and therefore they displayed weirdly. On Firefox
the arrow head that should have pointed to left pointed actually to right.
This commit fixes that problem by defining the marker ids correctly.
I tested on Firefox 40.0.3 that the arrow heads are now displayed correctly.
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tested-by: Bryce Harrington <bryce@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Internally we still use uint32_t because that's all we get from evdev. But
eventually we'll have 64 bit serials.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
struct list isn't a null-terminated list, list_for_each() causes 'g' to be set
to the list head at the end of the loop. Returning that as group caused random
memory to be overwritten.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Asus RoG Gladius exposes two event nodes, one mouse, one keyboard. The
keyboard node has REL_X/Y and REL_HWHEEL on top of the various key bits and
ABS_VOLUME.
The keyboard node does not have BTN_* set, udev tags this device as a
keyboard only, not as a pointer but we still initialize the pointer caps for
it because of the wheel.
When moving this mouse, some deltas (ca "1 in every 20") are sent through the
keyboard node, causing a crash because we never initialized pointer
acceleration.
https://bugzilla.redhat.com/show_bug.cgi?id=1275407
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This check is already in place for all other event types.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And use the unaccelerated motion events. Better than crashing, and better than
a non-moving mouse.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
