Previously, we had a hard threshold of 20mm per event frame. That is just
about achievable by really fast movements (in which case you don't care too
much about the jumps anyway because you've already hit the edge of the screen).
Sometimes pointer jumps have lower deltas that are achievable even on slower,
more likely motions. Analysis of finger motion has shown that while a delta
>7mm per event is possible, jumping _by_ 7mm between two events is unlikely
and indicates a pointer jump. So let's diff the most recent delta and the
current delta, if it increases by 7mm between two event frames let's say it's
a pointer jump and discard it.
Helps with but does not fully resolve:
https://gitlab.freedesktop.org/libinput/libinput/issues/80https://gitlab.freedesktop.org/libinput/libinput/issues/36
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The software button area is currently a partially-dead area. If the finger
moves into or out of the area pointer motion works. Finger motion within the
area however does not generate motion.
The main motivation for this was to avoid accidental pointer motion when a
button is pressed. This is required for stationary fingers but once you move a
significant distance, those bets are off.
So if the finger moves by more than 5mm from where it was put down, release it
and let it move the pointer.
The full impact is largely limited to horizontal movements within the button
area because:
- leaving the finger at the bottom area for 300ms without movement triggers
the thumb identification, so it won't move anyway.
- moving the finger north is likely to go off the button area before we
trigger this threshold.
https://gitlab.freedesktop.org/libinput/libinput/issues/86
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least not opening single quotes, same as the double quotes we already have.
Add the tests for both.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have a sensible use case where we want hex to double, or INF to
double, or any of that. So check the strings for invalid characters and bail
out early. Invalid characters include 'e' and whitespaces too, we don't need
those.
Small chance of things breaking: if the user-exposed calibration matrix
property was specified using hex numbers this will stop working now. I'll take
that risk.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let's use something that specializes in that task and does a better job of it
than whatever we'll come up with. Due to how it's implemented the stacktrace
will always show waitpid() as frame 0 now but we can live with that.
gstack prints to stdout but litest_log() uses stderr, so we cannot just call
system(), we have do do the pipe/fork/exec/waitpid/read dance.
We could use that to filter the #0 frame showing waidpid() from gstack but
meh.
This drops the libunwind and addr2line dependency and replaces it with gstack
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No need to rebuild everything with an ifdef, we can just use meson to pass an
argument to the test itself and filter based on that. This drops about 100
ninja targets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No touchpad gives us these events with a 0 delay, so let's not test for that.
This is required for adding timing-sensitive scroll code, see
https://gitlab.freedesktop.org/libinput/libinput/issues/101.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having this as the generic "synaptics" touchpad in the tests is not helpful,
this touchpad is tiny and quite special these days.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the same blurb everywhere, changing from the old style MIT to the Expat
license we're using everywhere else.
Similar to bc9f16b40e
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A three-finger touch may cause slot N to end, in a frame after the
BTN_TOOL_TRIPLETAP. This causes tp->nfinger_down to be decremented to 2 as the
touch switches to MAYBE_END - which happens to be our num_slots. We exit early
and never restore the touch correctly.
Fix this by checking that the number of fake touches is equal to the slots, if
it is higher then we need to check for recovery.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/99
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We want to autoreplace this value where possible but not scale it to min/max,
this is effectively an enum. The same is true for slot/tracking id, so let's
add it here too.
Because it's an enum and 99% of the cases require MT_TOOL_FINGER, we always
fall back to that instead of using the axis_defaults that we use for other
axes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The necessary helpers to test for a touch event + one touch frame and the
extra case for the TOUCH_CANCEL in is_touch_event
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Failing the leftover-rules check in the valgrind stage because
==1491== Invalid read of size 16
==1491== at 0x5320AE8: __wcsnlen_sse4_1 (in /usr/lib64/libc-2.27.so)
==1491== by 0x5310AD1: wcsrtombs (in /usr/lib64/libc-2.27.so)
==1491== by 0x1AA403: ??? (in /usr/bin/bash)
==1491== by 0x1AB3E3: glob_filename (in /usr/bin/bash)
==1491== by 0x179FF1: shell_glob_filename (in /usr/bin/bash)
==1491== by 0x1752CD: ??? (in /usr/bin/bash)
==1491== by 0x14C05F: ??? (in /usr/bin/bash)
==1491== by 0x14E2E3: execute_command_internal (in /usr/bin/bash)
==1491== by 0x14FBC5: execute_command (in /usr/bin/bash)
==1491== by 0x137598: reader_loop (in /usr/bin/bash)
==1491== by 0x135D38: main (in /usr/bin/bash)
==1491== Address 0x5651fd0 is 32 bytes before a block of size 128 in arena "client"
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no need for high performance in these little tests, so instead of
supporting various platform-specific sendfile() implementations, just use a local read-write function.
This hasn't been a real .in file since the autotools removal, so rename it to
reflect that. And since we can call it with arguments from meson, let's do so
in the most sensible manner - passing the full paths in as required rather
than relying on a directory layout within the script.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I keep hitting this in the gitlab runner, 100ms is clearly not enough here for
slow containers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
destroy isn't called until the last libinput_device_unref(), so we may trigger
a debounce timer after the device was removed. The same fix is neded for the
touchpad interface.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/72
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the args are bad, we don't need to check for root and whatnot.
Only exception here is the debugger check because it changes defaults that we
may want to override with commandline arguments later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The tapping code can handle palm states now, so there is no need to disable
tapping altogether when a tool-based palm is detected.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/65
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These are tests that don't need *any* uinput devices at all. Mark them
accordingly and create a new binary that only runs those tests. This way we
can run some of the test suite even in containers where we're restricted.
Better have 10% tested than none, I guess.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
value isn't touched where the quirk doesn't exist, so we're accessing an
uninitialized variable here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current /dev/input/* check isn't reliable enough. So rather than adding
extra heuristics prone to fail add an environment variable that says "do not
run the test suite runner". All other tests are run since they do not
require/modify any specific system setup.
Fixes https://gitlab.freedesktop.org/libinput/libinput/issues/62
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The ssize_t cast upsets coverity for some reason but we can be a lot more
restrictive here anyway. Quick analysis of the zalloc calls in the test suite
show the largest allocation is 9204 bytes.
Let's put a cap on for one MB, anything above that is likely some memory
corruption and should be caught early.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Matheus Santana <embs@cin.ufpe.br>
Leftover from a previous iteration of this code - having a static but
unnecessarily large size for dirname results in:
../test/litest.c:1251:38: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
snprintf(dest, sizeof(dest), "%s/%s", dirname, filename);
^
../test/litest.c:1251:3: note: ‘snprintf’ output 2 or more bytes (assuming 4097) into a destination of size 4096
snprintf(dest, sizeof(dest), "%s/%s", dirname, filename);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
