libunwind gives us a file and an address and usually a function name. Beyond
that, it's mostly guessing.
Fork off addr2line to resolve the addresses that libunwind gives us, if we
succeed we get a backtrace like this:
Backtrace:
0: litest_fail_comparison_int() (./test/litest.c:268)
1: disable_button_scrolling() (./test/pointer.c:115)
2: middlebutton_doubleclick() (./test/pointer.c:991)
3: /lib64/libcheck.so.0 (srunner_run+0x7f5) [0x7f6c12d8c025]
4: litest_run() (./test/litest.c:689)
5: main() (./test/pointer.c:1280)
6: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f6c11a73790]
7: ./test/test-pointer (_start+0x29) [0x403d99]
8: ? (?+0x29) [0x29]
Note: I intentionally swapped function/file name in the output to make it
easier to spot which one is fully resolved and which one is the basic
libunwind output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The check unit test framework isn't particularly suited to having ck_assert*
calls in helper functions. A failed assertion in a helper function or the
litest framework merely gives us a the failed line in litest.c.
which doesn't tell us which test actually failed.
Add a backtracing facility with litest_backtrace(). And since this requires
wrapping all ck_assert macros with litest_assert() this patch ended up
replacing/duplicating a bunch of ck_assert_* bits. So rather than
ck_assert_int_eq() we now use litest_assert_int_eq(), etc. in the litest
framework itself.
The int comparison macros are more type-safe than ck_assert()'s macros which
just cast all the ints to intmax_t.
Backtrace is spewed to stderr, which is good enough for debugging. Example
backtrace:
FAILED COMPARISON: status != expected
Resolved to: 0 != 0
in disable_button_scrolling() (pointer.c:115)
Backtrace:
0: ./test/test-pointer (litest_fail_comparison_int+0xab) [0x40973b]
1: ./test/test-pointer (disable_button_scrolling+0x174) [0x40421b]
2: ./test/test-pointer (middlebutton_middleclick+0x40) [0x40829c]
3: /lib64/libcheck.so.0 (srunner_run+0x7f5) [0x7f0e8a277025]
4: ./test/test-pointer (litest_run+0x107) [0x40a42b]
5: ./test/test-pointer (main+0x2fa) [0x4090e7]
6: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7f0e88f5e790]
7: ./test/test-pointer (_start+0x29) [0x403ce9]
8: ? (?+0x29) [0x29]
litest_backtrace() itself is copied from xserver/os/backtrace.c which git
blame attributes to Marcin.
CC: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No effect with the current macros since they'll cast to int for us, but this
will change with the litest_assert macros.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unfortunately, typeof(enum something) != typeof(ENUM_VALUE) and produces a
-Wsign-compare warning
Preemptively fix this, it'll show up in the upcoming litest_asssert macros
otherwise.
This fix only applies to helper functions, tests themselves wont (yet) be
switched to the new macros and don't need fixing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
unsigned vs signed in both cases, but the ck_assert macros hide that
(everything is cast to intmax_t). The upcoming litest_assert wrappers expose
these warnings, so fix them ahead of time.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hitting a single key triggers a short timeout, just enough to cover the time
to the next key event. Hitting more than one key triggers the longer timeout.
This should improve responsiveness after single key events when the touchpad is
still the main interaction mode and a key needs to be pressed to advance in
the UI. When typing the hands require physical movement to get back to the
touchpad anyway so a longer timeout is acceptable and more reliable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On some touchpads, typing triggers touches in areas of the touchpad that
cannot easily be distinguished from other fingers. Pressure information is
useless too, so we have to go back to a timeout-based handling of touch data.
If we see non-modifier key events, disable the touchpad for a timeout and set
any touches starting during that timeout as palm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Preparation to add different palm detection types. Not all of them need to be
un-done when leaving the edge area so a boolean is not enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently for the tap-and-drag gesture to end user has to wait for a
timeout to expire. Make it possible to end the drag gesture by just tapping.
The allowed finger sequences to start and end a drag are thus:
tap, down, .... move ...., up <wait for timeout>
tap, down, .... move ...., up, tap
https://bugs.freedesktop.org/show_bug.cgi?id=90255
Signed-off-by: Velimir Lisec <lisec.velimir@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
State diagram changes and a doc change squashed in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
"read(int, void *, size_t)" returns the number of bytes read, but it
is ignored.
We don't really care about the number of bytes, but let's complain if we get
anything but EAGAIN.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
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>
