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>
detect_pressure_offset() currently rejects offsets that are greater than
20%. My graphics tablet (Wacom Bamboo Fun) is about 30%. The pen tip is
2 mm. Wacom recommends replacing at 1 mm, which means this isn't worn
out yet and we should instead increase the limit to make these devices
usable.
Without this change a "pen down" event happens simultaneously with the
pen being detected -- about 1 cm above the surface -- and producing
libinput pressure of about 0.30. This means you start drawing "in the
air", without knowing up front where the cursor is going to be.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Previously we only applied pressure offset handling for tablets that
supported ABS_DISTANCE. Detecting a pressure offset when the tool
doesn't actually touch the surface is easy after all.
But tablets without distance handling may also have a pressure offset,
so let's try to detect this. This is obviously harder since the pen will
always touch the tablet's surface whenever it is in proximity and thus
will always have *some* pressure applied to it.
The process here is to merely observe the minimum pressure value during
the first two strokes of the pen. On the third prox in, that minimum
pressure value is taken as the offset. If the pressure drops below the
offset, the offset is adjusted downwards [1] so over time we'll
get closer to the pen's real offset.
[1] this is already done for distance tablets too
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ensure that if we do get pressure < offset that that offset is reduced
to the current pressure value.
The implementation for this is arguably buggy, reducing the pressure
means we get a tip up event since we now reach 0% of pressure. Arguably
we should enforce the tip staying down and releasing it later but since
this should typically never happen more than once per tool per context
and working around this is a lot of effort, we live with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Makes the code a bit easier to read. Adds precision to some tests,
slightly loosens precision in some other tests but that shouldn't matter
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Right now for touch arbitration to work, we require the device group to
be the same (i.e. they're hanging off the same physical bus). That's not
always the case and statistically we have a lot more devices that have
a built-in tablet + touchscreen than we have Intuos-like external
tablets.
So let's default to the more common case - enabling arbitration with the
first touchscreen/external touchpad we find. If a subsequent device is
"better", swap it out. Right now, the only heuristic we have here is the
device group check but in the future we could get more precise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A user was experiencing issues with their hand being recognized as
touch input above the stylus tip.
Since touch above the stylus should be rare, increase the touch
arbitration rectangle height by 50mm.
Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/809
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
When the libwacom build option is set to false the compiler throws
these warnings:
../udev/libinput-device-group.c:95:1: warning: ‘wacom_handle_ekr’ defined but not used [-Wunused-function]
95 | wacom_handle_ekr(struct udev_device *device,
| ^~~~~~~~~~~~~~~~
[205/237] Compiling C object 'libinput-test-suite@exe/test_test-tablet.c.o'.
../test/test-tablet.c:5440:1: warning: ‘verify_left_handed_touch_sequence’ defined but not used [-Wunused-function]
5440 | verify_left_handed_touch_sequence(struct litest_device *finger,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../test/test-tablet.c:5385:1: warning: ‘verify_left_handed_tablet_sequence’ defined but not used [-Wunused-function]
5385 | verify_left_handed_tablet_sequence(struct litest_device *tablet,
# | ^~~~~~~~~~~~~~~~
# | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Add the required guards to fix the warnings.
Fix#791.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Tools default to 1% lower threshold (tip up) and 5% upper threshold (tip
down). But our distance vs pressure exclusion would reset the distance
for *any* pressure value, regardless how low that value was and how high
distance was in comparison.
A very low pressure value of less than 1% would then result in a
normalized pressure of 0, so we'd effectively just reset the distance to
zero and do nothing with the pressure. This can cause distance jumps
when the tool arbitrarily sends low pressure values while hovering as
seen in https://github.com/libsdl-org/SDL/pull/5481#issuecomment-1118969064
Commit 61bdc05fb0 from Dec 2017
"tablet: set the tip-up pressure threshold to 1%"
was presumably to address this but no longer (?) works.
Fix this by addressing multiple issues at the same time:
- anything under that 1% threshold is now considered as zero pressure
and any distance value is kept as-is. Once pressure reaches 1%,
distance is always zero.
- axis normalization is now from 1% to 100% (previously: upper threshold
to 100%). So a tip down event should always have ~4% pressure and we
may get tablet motion events with nonzero pressure before the tip down
event.
From memory, this was always intended anyway since a tip event should
require some significant pressure, maybe too high compared to e.g.
pressure-sensitive painting
- where a tablet has an offset, add the same 1%/5% thresholds, on top of
that offset. And keep adjusting those thresholds as we change the
offset. Assuming that the offset is the absolute minimum a worn-out
pen can reach, this gives us the same behaviour as a new pen. The
calculation here uses a simple approach so the actual range is
slightly larger than 5% but it'll do.
Previously, the lower threshold for an offset pen was the axis minimum
but that can never be reached. So there was probably an undiscovered
bug in there.
And fix a bunch of comments that were either wrong, confusing or
incomplete, e.g. the pressure thresholds were already in device
coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because --filter-test does substring matching it's easier to have it
with a unique name rather than one that is a prefix of another.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Certain tests that make use of verify_left_handed_touch_motion can fail
depending on how quick they are executed, specially when using Valgrind.
Instead of ignoring the hold end event, use the existing mechanism to
disable hold gestures where we are not interested in them.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Depending on how quick the test suite runs we may get a hold end event
here. Let's silently ignore that one since we aren't interested in it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add two helper functions that set/unset BTN_TOUCH together with the
specified axes and switch all tests over.
Devices can override the tip down/up sequence.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Hold gestures are notifications about fingers on the touchpad.
There is no coordinate attached to a hold gesture, merely the number of fingers.
A hold gesture starts when the user places a finger on the touchpad and
ends when all fingers are lifted. It is cancelled when the finger(s) move
past applicable thresholds and trigger some other interaction like pointer
movement or scrolling.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The group names are forced by check (they are called suite names there) but
for our test suite they provide very little benefit. Much easier to just
use the filename a test is in as group name.
This removes the pure substring match for --filter-group, it's now fnmatch
only. group names are short enough that the typing isn't an issue and we don't
want to run tests twice (e.g. 'pad' is also in 'touchpad').
This patch caused #574 until it got fixed in d838e3a3a4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
litest itself requires the libinput user_data to be set to its own context
struct (see close_restricted). A test that needs its own user_data must not
override this struct - if the context is accessed during libinput_dispatch()
we'll get memory corruption.
See #574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Data in
https://gitlab.freedesktop.org/libinput/libinput/-/issues/225#note_379034
suggests that AES devices have lower noise than the older EMR
devices, so let's try disabling it for those devices.
We can't directly get the AES devices in libinput unless we want to add a
whole bunch of quirks for the various vid/pid combinations. But we can get
that info from libwacom, primarily because we know that libwacom will list all
known AES pens for any device. So we can check for one that we know of (0x11)
and if it's in the list, the tablet is an AES tablet.
Setting the history size to 1 means we never do any actual smoothing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All minor:
- execdir does not need initialization, it's not used until written to
- 'newest' could be NULL
- zalloc(-1) confuses coverity
- 't' is never used in that test
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only worked because of axis smoothing mangling the coordinates - x is not
supposed to change where we're moving along a vertical line. And the same for
y and horizontal lines.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test only worked because axis smoothing mangled the coordinates, moving
from 5/10 to 10/20 cannot possibly have a dx of zero.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the device from
https://gitlab.freedesktop.org/libinput/libinput/-/issues/259 which sets
BTN_TOOL_PEN in addition to the real tool. Integrate this into the test device
proper so it always does this to catch various outliers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
More realistic, there's no way you can get the x/y coordinates exactly the
same when moving the pen back into prox.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current tool type test merely sends BTN_TOOL_RUBBER (and others) manually
and expects libinput to do the right thing. This only tests the perfect
sequence but not test weird devices that behave differently on a tool type
switch.
So let's fix this by setting the tool type as property on the libinput test
device itself, and then emulate the tool switch through litest.
For special devices this will need extra callbacks, this is just the initial
framework to handle those buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test only worked because we're emulating events that the device never
sends that way. Just skip the test, devices that require a forced prox out
probably don't handle (or even have) erasers ayway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Symmetrical to litest_create_context(), this allows us to store special data
in that context that we have access to during the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This somewhat duplicates the existing test
huion_static_btn_tool_pen_disable_quirk_on_prox_out
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the previous patches a tablet would ignore a valid proximity out sequence
where it happends after a forced prox-out. Fix this by checking the state when
we're in forced proximity out - if we have a zero tool state but a tool
updated then we did get a proximity out.
And fix the existing test to check for that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This quirk was introduced for #248 was caused by buggy input-wacom drivers,
not by actual firmware, see
https://gitlab.freedesktop.org/libinput/libinput/issues/381#note_279371
This appears to be the only tablet where this fix was needed, but we've been
playing whack-a-mole ever since to work around the various other tablets that
break with this behavior in place.
So let's revert that fix and hope there aren't any other tablets out there
(and if they are, we can probably quirk those). The revert makes the ISDV4 pen
quirk obsolete (see 9cb089f2b6), so this was
folded into this commit.
This reverts commit 4f63345b60.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of these may have a non-libwacom solution but let's be honest, you
shouldn't be skipping libwacom if you rely on tablets to be precise.
Fixes#436
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While buttons are down, don't let a forced proximity out happen. If the tablet
goes out of proximity normally that's fine but we don't force a proximity out.
Remains to be seen if this causes stuck buttons now on devices that rely on
the forced proximity out...
Fixes#403
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We know we should have an event here, so we might as well process it
immediately to speed the error case up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
