We never want to accidentally trigger this one. Where we trigger them on
purpose, we can swap the log handler out first.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This forces events for every ~10ms now. If we want a slower movement, we need
more steps - just like a real touchpad does it.
Cocinelle spatch files were variants of:
@@
expression A, B, C, D, E, F, G, H, I, J, K;
@@
- litest_touch_move_two_touches(A, B, C, D, E, F, G, H, I)
+ litest_touch_move_two_touches(A, B, C, D, E, F, G, H)
The only test that needed a real fix was touchpad_no_palm_detect_2fg_scroll,
it used 12ms before, now it's using 10ms so on the bcm5974 touchpad the second
finger was a speed-thumb. Increasing the events and thus slowing down the
pointer means it's a normal finger and the test succeeds again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Change a number of tests to use 10ms intervals between finger events and fix
the coordinates up accordingly to avoid pointer jumps. This is in preparation
for a test-suite wide use of 10ms intervals.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
move_to() now uses delays, let's make this test more robust for timing errors
so we don't fall below the threshold movement we want to trigger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The coordinates ended up being in the first touch detected as palm. Not
relevant for this test, but let's not do that to avoid false positives.
Also change to 10ms intervals, more realistic given the hardware.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once we start working with real event frames (i.e. intervals after SYN_REPORT)
we'll always trigger the proximity timeout here. Avoid this by sending one
event with all buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test only succeeded because all events were sent within the dwt timeout.
Change it to actually test the behavior of a touch being disabled by DWT and
staying disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These only succeeded because the test suite doesn't use frame intervals - as
soon as the time between event frames is nonzero, we may fail these.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can use the _extended version here. And it turns out the behavior was
slightly different, with the _extended version doing one step too few.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
