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>
Now that we have a wiki page let's link to it, it has all the details
on how and why we (plan to) do this.
Also change the wording to be make it easier to anthropomorphize bugbot
when it adds that comment, ideally leading to fewer grumpy users.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1093>
We have labels like needinfo or triage needed but all these labels
require intervention from a privileged user - normal users cannot
set labels on a project.
The only thing users can all do is open/close/re-open bugs. So let's try
to incorporate this into our event flow: if we need something from the
user we ask for it, close the bug and when the user supplies this
information they can re-open it. This means e.g. bugs waiting forever in
triage will not show up as actionable in the issue list.
Since users aren't used to that workflow let's add a bugbot blurb that
explains that we're not really closing the issue, just using that as the
only lever we have available.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1090>
If we get to SWIPE_START we send out the BEGIN event and transition to
state SWIPE. We must not process that state immediately to avoid sending
out a spurious UPDATE event when nothing has changed.
Same for the PINCH_START/PINCH and SCROLL_START/SCROLL states.
This also fixes a crasher where we end up with NaN in the custom
acceleration function because passing the same timestamp in twice causes
a division by zero (delta time is zero).
Closes#1053
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1088>
