Require the type to be added in the litest_test_params_fetch() so we can
easily detect a mismatch. And add some type-safe getters that are much
easier to use for all the tests that only have a single parameter to
fetch anyway.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1139>
This is a workaround for a kernel bug with the Wacom Mobile Studio Pro
13: this device sends erroneous ABS_WHEEL events when pressing
buttons:
- evdev:
- [ 0, 0, 1, 256, 1] # EV_KEY / BTN_0 1
- [ 0, 0, 3, 8, 17] # EV_ABS / ABS_WHEEL 17 (+17)
- [ 0, 0, 3, 8, 0] # EV_ABS / ABS_WHEEL 0 (-17)
- [ 0, 0, 3, 40, 15] # EV_ABS / ABS_MISC 15 (+15)
- [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
ABS_WHEEL to 17 then to 0 in the same frame. We should (and do) treat this
as a zero event and drop the 17 to the floor. Alas, we then generate a
ring event for the zero value despite our current value being zero
anyway. This again causes confusing behavior.
This is simple enough to work around, at least until the kernel is fixed
but also to prevent this happening in the future: warn if we get
multiple events and if so and the later event is zero, undo the axis
change state.
Closes: #1081
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1136>
Slightly less efficient but easier to read and it's not possible to
accidentally provide the wrong length. Plus it handles null pointers
correctly so get to skip the checks (which weren't needed for strneq()
either, but still).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1121>
The previous invocation was gated behind a TABLET_OUT_OF_AREA check
resulting in a nonresponsive tool when the tablet was moved out of
proximity outside the tablet area and the area was changed.
Move the actual status bit changes up into tablet_flush()
so we unconditionally set those.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1118>
This makes it easier to quickly gather how far a touch has moved since
it started, compared to the initial starting position. This again makes
it easier to determine if a threshold required for e.g. scrolling has
been met.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1101>
The previous implementation skipped parameters that were filtered, so
our test cases got called with parameters missing. Fix this by filtering
any test case that has a negative fnmatch on any parameter.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1120>
We don't have an API for "device really should have tapping enabled" so
right now the only indicator of whether that's the case is when the
device has tapping enabled by default. This kind of prevents us from
switching the default, so let's at least link to the comment explaining
this.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1115>
litest supports ranged tests but they are not enough, doubly so with
tests where we want to parametrize across multiple options.
This patch adds support for just that, in clunky C style.
The typical invocation for a test is by giving the test parameter
a name, a number of values and then the values themselves:
struct litest_parameters *params = litest_parameters_new("axis", 's', 2, "ABS_X", "ABS_Y",
"enabled", 'b', '2', true, false,
"number", 'u', '2', 10, 11,
NULL);
litest_add_parametrized(sometest, LITEST_ANY, LITEST_ANY, params);
litest_parameters_unref(params);
Currently supported are u (uint32), i (int32), d (double), b (bool),
c (char) and s (string).
In the test itself, the `test_env->params` variable is available and
retrieval of the parameters works like this:
const char *axis;
uint32_t number;
bool enabled;
litest_test_param_fetch(test_env->params,
"axis", &axis,
"enabled", &enabled,
"number", &number,
NULL);
Note that since this is an effectively internal test-suite only
functionality we don't do type-checking here, it's assumed that if you
write the code to pass parameters into a test you remember the type
of said params when you write the test code.
Because we don't have hashmaps or anything useful other than lists the
implementation is a bit clunky: we copy the parameter into the test
during litest_add_*, permutate it for our test list which gives us yet
another linked list C struct, and finally copy the actual value into
the test and test environment as it's executed. Not pretty, but it
works.
A few tests are switched as simple demonstration. The name of the
test has the parameters with their names and values appended now, e.g.:
"pointer:pointer_scroll_wheel_hires_send_only_lores:ms-surface-cover:axis:ABS_X"
"pointer:pointer_motion_relative_min_decel:mouse-roccat:direction:NW"
Filtering by parameters can be done via globs of their string
representation:
libinput-test-suite --filter-params="axis:ABS_*,enabled:true,number:10*"
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1109>
../../../src/util-files.h:61:3: warning: The 1st argument to 'close' is <= -2 but should be >= -1 [unix.StdCLibraryFunctions]
61 | close(*fd);
../../../test/test-quirks.c:66:8: warning: Null pointer passed to 2nd parameter expecting 'nonnull' [core.NonNullParamChecker]
66 | rc = fputs(file_content, fp);
The latter is bogus because we have a litest_assert for this but
somehow this is ignored, so... shrug.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1111>
If libinput replay is currently replaying events, stop that sequence and
go back to the start if the user presses Ctrl+C. Only on the second
Ctrl+C do we fully exit.
This helps debugging long recordings where we don't want to keep
producing events after some initial event sequence.
Closes#1064
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1102>
