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>
This was always intended but a bug prevented the actual abort.
strstr returns NULL when we cannot find the substring so we always
triggered the first noop condition on bugs.
Fixes: bd7b91065b ("evdev: warn if our event processing lags by 10ms or more")
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1048>
This allows for a slight optimization of the quirks parser: where
multiple devices from the same vendor require the same quirk, allow
for multiple product matches in the form:
MatchProduct=0x0001;0x0002;
This is stored as a fixed-sized zero-terminated array - a product ID of
zero isn't something we need to worry about in real situations.
Closes#879
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1038>
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>
We ignore modifiers for disable-while-typing because we don't want to
disable the touchpad for things like shift-click or ctrl-click.
We also do remember the modifier state so that we don't disable the
touchpad for once-offs like ctrl+s.
Shift is however a special case - shift + something else is means the
user is typing and we should disable the touchpad for that.
Closes#1005
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1015>
Same as MatchName but matches on the UNIQ udev property instead. This
is needed for some Huion, Gaomon and other tablet devices that only
differentiate each other through the Uniq string which contains the
firmware version.
Closes#997
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1006>
This are tests with drag lock enabled, so our timeout needs to be
be the tap and drag timeout (which is higher than the normal tap timeout).
Only worked because they're similar enough that if there's a bit of a
delay, the extra ms push us over the line.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
In touchpad_2fg_scroll_return_to_motion we sometimes fail because the
timeout is too close to the actual timeout expiry, creating a race
condition on whether the scroll stop event (triggered by the gesture
end) is sent before or after the timeout expiry.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
We're writing a lot of events here, if the system isn't fast enough or
(in the future) if we have a custom socket instead of a kernel device we
might fill up the write buffer, causing the test to fail.
Easy workaround is to dispatch more often to ensure the data is being
read from the fd.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/984>
Some tablets such as those in the XP-PEN PRO series use "dials" which
are actually scrollwheels and emit EV_REL events. These should not be
emulated as rings (which are absolute) so we must expose them as a new
tablet event.
Adds LIBINPUT_EVENT_TABLET_PAD_DIAL that work largely identical as our
high-resolution wheel events (i.e. the values are in multiples or
fractions of of 120). Currently supports two dials.
This is a lot of copy/paste from the ring axes because the interface is
virtually identical. The main difference is that dials give us a v120
value in the same manner as our scroll axes.
Notes:
- REL_DIAL is mutually exclusive with REL_WHEEL, we assume the kernel
doesn't (at this point) give us devices with both. If this changes for
devices with three dials (wheel + hwheel + dial) we need to add code
for that.
- REL_DIAL does not have a high-resolution axis and we assume that any
device with REL_WHEEL_HI_RES will also have REL_HWHEEL_HI_RES (if the
second wheel exists).
- With dials being REL_DIAL or REL_WHEEL there is no possibility of
detecting a finger release (the kernel does not route EV_RELs with a
value of zero). Unless this is implemented via a side-channel - and it
doesn't look like any hardware that supports dials does that - we
cannot forward any information here. So unlike absolute rings we
cannot provide a source information here.
Closes#600
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
BTN_0 is the only one guaranteed to exist (otherwise we skip the test)
so let's ensure we have at least one event - all the others will fail if
we don't get the right event sent.
This enables the test to run against devices that only have one button.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
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 a test goes past the tip-down threshold, the proximity timeout does
not trigger. And one can spend a long time trying to debug why the test
fails...
As far as I vaguely remember, these devices' pressure values are correct
enough, it's just the lack of BTN_TOOL_PEN that is the issue so instead
of a proper proximity out, we just send enough data to set the pressure
to below the tip threshold.
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
Where a more generic match assigns a palm threshold to a device, allow
unsetting this by assigning a threshold of zero.
And remove the bug log for palm size threshold of 0 for the same reason.
Group the LITEST_FOO enum into sections for touchpads, mice, etc. This
makes it easier to find whether a particular device may have a
representation already.
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>
