litest_add_ranged* takes a range parameter that serves as the lower/upper
boundary for a loop. This enables tests to be run multiple times, avoiding the
timeouts we triggered by having the loops inside (e.g. see 2bf8d035c and
6dd02468).
This just wraps the underlying check framework, the ranged variable is
available as "_i" in the test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Run the touchpad tests first, it's the most likely to fail. It also takes the
longest, so it's annoying to have it fail when you spent a minute watching the
other tests succeed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
When the device supports true hovering, it reports this
information through ABS_MT_DISTANCE.
When this axis is available, we should rely on it to
(un)hover the touches as BTN_TOUCH is most of the time
unreliable (generated by the mouse emulation in the kernel).
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This code was largely lifted from the X server in
bb25b2ad29 but didn't take the copyright messages that
applied to that code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
Acked-by: Simon Thum <simon.thum@gmx.de>
The current hover tests are uniquely designed for some Synaptics
touchpad. libinput can handle hovering through ABS_MT_DISTANCE,
so we need to reserve the "hover" name for real hovering devices.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Causes an error message in the device_disable_release_tap_n_drag test. When
the touchpad is suspended, all touches are ended in tp_clear_state. Since the
hovering support was added, this returns the touches to TOUCH_HOVERING, a
subsequent tp_handle_state() will turn them back into TOUCH_BEGIN based on
BTN_TOUCH and BTN_TOOL_FINGER still being down.
Clear the fake touch buttons as well after ending the touches, this way the
touch points are reset to TOUCH_NONE as intended.
Once we do that we don't need to manually change the tap finger count when
releasing taps, we can just let the count reset naturally.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Use tp->nfingers_down as trigger when we have no fingers left on the touchpad
and when we should return to idle. If all touchpoints end in the same frame
tp->nfingers is 0. Thus when we handle the first tap release we transition to
IDLE which now needs to handle (and discard) any touch release events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Bonobo, Clevo, Galago and Kudu have clickpads and no markings ->
enable clickfinger by default.
Lemur and Gazelle have physical buttons, no need for extra configuration.
https://bugs.freedesktop.org/show_bug.cgi?id=90170
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This matches the vendor default.
Board IDs pulled from modinfo chromeos_laptop, touchpad names from a bit of
googling around.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libinput supports lifting a finger during dragging and setting it back down
again to continue the drag. Curently the drag timeout is set to
DEFAULT_TAP_TIMEOUT. That is to short, when we're dragging the finger needs to
have enough time to move from one edge of the touchpad to the other. 180ms is
too short for that and causes false timeouts and thus button releases that
cancel the drag.
Introduce DEFAULT_DRAG_TIMEOUT and set it to 500 ms.
Signed-off-by: Velimir Lisec <lisec.velimir@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current doubletap timeout was incorrect, it gave the user only 180ms to
touch, release, touch, release to recognise a doubletap. But it would also set
a timeout on the second release, delaying the button events by 180ms.
Instead, re-arm the timer on the second touch down. This gives the user 180ms
to release and touch again (or time out). This makes doubletap much more
reliable and reduces the delay between the release and the button events
arriving since the finger down time is already counted.
Same fix for MULTITAP, though we already armed the timer on touch down so we
just have to remove the new timer on touch release which did little but delay
everything.
https://bugs.freedesktop.org/show_bug.cgi?id=90172
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prep work for the upcoming patch to extend the timeout for tap-and-drag. And
switch the tests that rely on it over to the new function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Resetting a timerfd empties the data on the fd, so if the timer is reset
between triggering and us reading it, we may block trying to read it.
Since we read events off a device in a loop, a device sending a continuous
flow of events may cause the timer to trigger but delay reading it. If one of
the events cause e.g. the tap timer to be set, the timerfd may be empty at the
time of reading.
Suggested-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We'd rather keep these out of the hands of children.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rebuild the same binary but without the special LDFLAG. The event-debug tool
is left as-is to allow for easy debugging with gdb, the new tool is now
libtool-enabled and can't be run directly in gdb without installing it first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libevdev filters the ABS_MT_TRACKING_ID event for a double-touch down like
this so we never see this in libinput. We see an error message from libevdev
but otherwise this test is a false negative.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduced in 6b6f8151a4, libinput-version.h is
in the builddir.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes debugging a bit easier when you can just ask users to do that instead of
digging around in whatever packaging system they have.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
If we have a middle button but no wheels, enable on-button scrolling for the
middle button by default. This applies e.g. to the Logitech trackball added as
new test device here.
This makes the separate check for POINTINGSTICK obsolete but I'd rather leave
this in to be more explicit about it.
https://bugs.freedesktop.org/show_bug.cgi?id=90208
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of excluding the pointing stick devices, disable middle button
scrolling on those and run them anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Released the wrong touch point, causing warnings:
libevdev error in sanitize_event: BUG: Device "litest SynPS/2 Synaptics
TouchPad" received a double tracking ID 6 in slot 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Almost identical to the one we already had but this one also has ABS_X/Y to
mess things up. Update the existing one, no need to add a separate device here.
The fake MT touch test needs to be updated now though. A fake MT device may be
an absolute device too, so if we use the touch_down() handlers we may generate
abs pointer events. That's valid, we only check for no touch events here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Some devices provide abs x/y and rel x/y. We can't know which event the device
will send. The Microsoft Surface Type Cover sends relative events, which
then crashes libinput when we don't have an accel filter set up.
So instead of checking that the device doesn't have ABS_X/Y, check for the
device to have REL_X/Y instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1206869
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Not sure if any exists, if they do let's see if a user files a bug report
first so we know what to do with those (they're most likely buttonsets).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Added in d2842893a8 but never added to the list
of devices so none of the tests ran against it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
