A tablet with multiple mode toggle buttons had each mode toggle button
merely cycle to the next mode in the sequence, removing the whole point
of having multiple toggle buttons.
Fix this by defaulting each mode toggle button to "next". Once we
have initialized all buttons we can check if we have multiple buttons -
if so we number them sequentially so that the first button maps to mode
0, the second maps to mode 1, etc.
Closes#1082
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1132>
This was working on an assumption that there is only one ref of the
tablet tool and if we call unref it will be removed. This assumption is
not something we can guarantee in the public API so we shouldn't test
for it.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1161>
This avoids inconsistencies between the LITEST_ enum value and the
shortname but also makes it easier to grep for any test cases that use
the same define. At the cost of the test names not looking very nice
anymore but oh well.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1157>
Tablets may have different ABS_PRESSURE ranges with the oldest tablets
having 1k pressure range, then 2k, and the newer ones 8k.
If the same tool is used across two tablets with different ABS_PRESSURE
ranges, the first tablet in proximity calculated the range on where to
normalize to. As a result the other tablet either couldn't reach the
full pressure (2k pressure first, then 8k) or the full pressure range
was reached at a fraction of the full range (8k pressure first, then
2k).
Fix this by moving the threshold handling into a separate struct and
hardcoding up to 4 of those per tool. That is 2 more than the more
complicated setups I've heard of (and this only applies to tracking the
same stylus across those tablets anyway).
This duplicates the pressure offset heuristics but that's easier than
figuring out how to handle heuristics across potentially two tablets.
The range configuration is left as-is on the assumption that this one is
per tool, not per tablet.
Closes#1089
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1143>
touchpad_move_after_touch contains support for up to 5 fingers but was only run
with 2..4 fingers.
touchpad_multitap and several others using the same parameter definition were
long ago tested with 3..7 taps. In 8f92b091 this was reduced to 3..4 for CI
performance, while the commit message indicates 3..5 were intended.
The common theme is that the upper bound of `struct range` is interpreted
as exclusive, while some uses assumed it would be inclusive.
There are relatively recent helper functions range_init_inclusive and
range_init_exclusive (since 817dc423) to avoid this trap. Use them on the
remaining two ranged tests.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
The two remaining ranged tests (abs_device_no_range, abs_mt_device_no_range)
are better served staying with ranges because parametrized tests need to
explicitly list all members of the range, which for these tests is not only
pretty big, but also contains abs axes reserved for future use. Those axes
have no names yet, making a future-proof conversion pretty much impossible.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
Exposed via new configuration option this enables 3 and 4 finger
dragging on touchpads. When enabled a 3/4 finger swipe
gesture is actually a button down + motion + button up sequence.
If tapping is disabled the drag starts immediately, if tapping is
enabled the drag starts after the tap timeout/motion so we can distinguish
between a tap and a drag.
When fingers are released:
- if two fingers remain -> keep dragging
- if one finger remains -> release drag, switch to pointer motion
When 3/4 fingers are set down immediately after releasing all fingers
the drag continues, similar to the tap drag lock feature. This drag lock
is not currently configurable.
This matches the macos behavior for the same feature.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
The 5th finger was placed in the same position as the 4th finger which
doesn't have an effect in libinput but it looks wrong.
And the first finger was put down at 40/30 but then moved from 70/30 to
the new position, causing pointer jumps on some touchpads.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1145>
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>
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>
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>
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 a tablet has an area configured and the pen goes into proximity
outside this area, ignore all events from this sequence. This truly
deactivates that area so it can even be used for e.g. placing a pen
there.
For simplicity, a sequence that starts outside the configured area will
be completely ignored, i.e. moving into the tablet area will not trigger
any fake proximity events as we cross into the allowed area. This
requires quite a bit of effort and it's unclear if it's really needed by
users - we can reconsider when we get complaints.
We do however accept a proximity event within within 3% of the
configured area. This gives us 6mm on a 200mm tablet where we can move
in from the area and still have events work, i.e. some error margin for
where a user needs both an area and work closes to the edge of that
area.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
For external tablets like the Intuos series we now expose the area
rectangle configuration and the (minimum) implementation required to
make this work.
Because an area configuration may apply late and tablet events usually
get scaled by the compositor we need to store the current axis extents
in each event. This is to behave correctly in this events sequence:
1. tool proximity in
2. caller changes config, config is pending
3. tool moves, generates events
4. tool goes out of prox, new config applies
5. caller processes motion events from step 3
If the caller in step five uses any of the get_x_transformed calls these
need to be scaled relative to the original area, not the one set in
step 2.
The current implementation merely clips into the area so moving a stylus
outside the area will be equivalent to moving it along the respective
edge of the area. It's not a true dead zone yet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
The vast majority of devices that libwacom doesn't know about are the
various built-in ones. Since the only effect in our code here is that we
enable the calibration matrix, let's default to built-in if we don't
know any better - better to have the matrix and not use it than to not
be able to calibrate a tablet.
Note that libwacom 2.11 and later also now default to a built-in tablet.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1074>
This test does a prox in/out and immediately drains events.
Where we are slow enough we may drain only one (or none) of the
proximity events which causes a failure later in the test.
Similar issue with the second test where we may get a delayed tip event.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1074>
