Commit 48cd4c7287 ("tablet: track pressure ranges per tablet") added
up to 4 per-tablet pressure ranges that are stored in the tool on the
assumption that tools are never used across more than 4 tools.
However, if the tablet gets unplugged it will show up as new devices.
Fix this by removing the tool's reference to the previous tablet after
device removal.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1165>
When the tool is moved in proximity of a new tablet but the pressure
range hasn't changed since the last proximity, the new tablet was left
with a threshold range of 0:0.
For some reason this requires tightening up the check for the test too,
with our default episolon 0.091 fails the test of being > 0.9
Closes#1109
Fixes: 48cd4c7287 ("tablet: track pressure ranges per tablet")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1165>
Modifies an existing proximity test to also test for the case where a
tablet never sends BTN_TOOL_PEN so we have that case covered.
This is implicitly tested by the LITEST_UCLOGIC_TABLET test device but
making it explicit is a bit easier to debug.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1164>
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>
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>
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>
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>
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>
This replaces check. The code is a copy of pwtest which I wrote years
ago for pipewire but adjusted for us here the last few days.
There are a few advantages over check:
- Ability to SKIP tests or mark them as NOT_APPLICABLE, the latter
of which is used for early checks if a device doesn't meet
requirements.
- it captures stdout/stderr separately
- colors!
- YAML output format makes it a lot easier to read the results and
eventually parse them for e.g. "restart failed tests"
Less abstraction: we set up the tests, pass them to the runner and run
them with the given number of forks. This is an improvement over before
where we forked into N test suites which each called check which then
forked again. Since we're now keeping track of those processes
ourselves we can also write tests that are expected to fail with
signals.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1067>
This is the first step in switching away from the check framework.
Our litest macros already do almost exactly the same anyway so most of
this is a simple sed with a few compiler fixes where things mismatch
(nonnull -> notnull) and (_tol -> _epsilon).
This now generates a whole bunch of integer mismatch warnings: check
casts everything to intmax_t whereas we use typeof, so lots of warnings
especially for enums.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1059>
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>
Not all display tablets have INPUT_PROP_DIRECT SET (looking at you,
Huion Kamvas 12) so our calibration went nowhere. Let libwacom override
whatever the kernel says.
This also makes testing without matching hardware a bit easier now since
we only need to override the libwacom file, not the whole device.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1019>
Add a configuration option to reduce the available hardware range to a
fraction thereof. This is done by copying the absinfo struct for the
pressure value and adjusting that copy's minimum/maximum value for
scaling into the target normalized range.
The 1%/5% tip thresholds are kept but pressure offset detection is
disabled if there is a custom pressure range.
Unlike the pressure curve which is implemented in the compositor, the
pressure min/max range needs to be in libinput, primarily because the
tip threshold needs to adjust to any new minimum, allowing for
light touches with a pen without triggering tip down even at a higher
hardware pressure.
The tablet tilt range may be set as [-N, M] in which case we assume that
a value of zero is vertical (and thus should result in a libinput tilt
value of zero). Unfortunately some tablets report an even total value
range, e.g. [-64, 63] so zero is not actually the mathematical center of
the axis.
Fix this by bumping the axis maximum so zero becomes the logical center.
All devices we've seen so far have [-A, (A-1)] as range so bumping it by
one makes it symmetric.
Like the input axis, a normalized range has min/max inclusive so we
cannot use the absinfo_range() helper which assumes the max is exclusive.
Reverts parts of 4effe6b1b9
And add a test to make sure the tool we know that has three buttons (Pro
Pen 3) can send all those. Enough to run that test one one compatible
device, no real benefit of running it on all tablet devices.
If libwacom is disabled or there is no .tablet file in libwacom for this
device yet, default to enabling a left-handed setting. Otherwise the
tablet may not be usable.
See https://github.com/linuxwacom/libwacom/issues/616
The range is (max - min + 1) because the kernel range is inclusive min
and max. Let's fix that once and for all with a helper function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
