These events aren't used to signal scroll/swipe/pinch/..., merely to
signal the start of that gesture. So let's rename it to make the code
clearer (e.g. why do we log a bug when for a FOO event when we're in
state FOO?).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
Confusingly, tp_gesture_handle_state() would do almost nothing with our
state machine and the various tp_gesture_handle_state_foo() were called
later from tp_gesture_post_gesture().
Rename those functions into so that we have
tp_gesture_update_finger_state() first followed by
tp_gesture_handle_state() which is responsible for dealing with the
state machine.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1049>
marge-bot rebases and edits the commit message but there's not way for
it to introduce a memleak that wasn't spotted in the user pipeline
first. Since those tests are very flaky, let's skip them when running
the marge-bot pipeline.
Closes#1042
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1057>
Wraps libinput_dispatch() with a location which will make things a bit
easier to track. Output (in --verbose) is something like:
gestures_swipe_3fg_unaccel_fn():1346 - dispatching
Which makes it easier to associate the various calls to libinput
dispatch with the other output from libinput.
This patch switches all uses of libinput_dispatch() in test cases over
but not the litest functions that may call dispatch too. Remains to be
seen if that is necessary.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1048>
This was always intended but a bug prevented the actual abort.
strstr returns NULL when we cannot find the substring so we always
triggered the first noop condition on bugs.
Fixes: bd7b91065b ("evdev: warn if our event processing lags by 10ms or more")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1048>
Our valgrind jobs are very timing-sensitive so it's very common that
they fail with an error when the reason is just valgrind being slower
and we miss a deadline somewhere.
Retry them if they fail, hopefully that gives us more reliable
pipelines.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1040>
If --compress-motion-events is given (and stdout is a tty) reduce
the output printed to one line per repeated motion/axis/scroll sequence
(with a count). Example output:
event6 POINTER_MOTION 108 +1.912s 1.00/ -1.00 ( +1.00/ -1.00))
event6 POINTER_BUTTON +2.008s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_BUTTON +2.074s BTN_LEFT (272) released, seat count: 0
event6 POINTER_MOTION 39 +5.249s 0.00/ 0.99 ( +0.00/ +1.00)
event6 POINTER_BUTTON +5.385s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_MOTION 66 +6.031s -1.00/ 0.00 ( -1.00/ +0.00)
event6 POINTER_BUTTON +6.401s BTN_LEFT (272) released, seat count: 0
The event count (108, 39 and 66) is only printed for more than one event
in sequence so the output is otherwise identical (but 4 spaces wider
now)
If stdout is not a tty the event count is printed but no compression
happens since we rely on a ansi escape sequence for that. Could be fixed
by changing the current print statements to print a \n before the
current event instead of at the end of the current line.
This makes debugging events easier as button events and similar are no
longer obscured by pages of motion events in between.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1041>
This allows for a slight optimization of the quirks parser: where
multiple devices from the same vendor require the same quirk, allow
for multiple product matches in the form:
MatchProduct=0x0001;0x0002;
This is stored as a fixed-sized zero-terminated array - a product ID of
zero isn't something we need to worry about in real situations.
Closes#879
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1038>
