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>
device->abs.absinfo_x/y points to the x/y axis we want to use and
that axis is used in all the evdev helper function. For consistency
use that one here too.
This is for consistency only and has no effect on tablet devices, the
only time this isn't ABS_X/Y is on multitouch devices where that points to
ABS_MT_POSITION_X/Y.
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>
Instead of re-creating the the libwacom device from the database every
time we need it let's create it once during tablet|pad_init and pass it
down to the functions.
This allows us to have one point per tablet/pad where we can log an
error if the device is not supported by libwacom - previously this was
printed during the left-handed setup.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1073>
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
Fixing the range is only required when the output range is not inclusive
of the min/max (such as when mapping an abs axis to a screen width).
Our pressure range is inclusive 0.0 and 1.0, so we want absinfo->maximum
to map to exactly 1.0
This reverts commit a5b6f4009b.
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.
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>
detect_pressure_offset() would previously update an existing offset but
otherwise skip most of the work for any event other than proximity-in
events. This was too hidden, let's split this into two functions - one
to update an existing offset and another one to detect a new offset.
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>
Previously the arbitration rectangle would be moved to lie completely in
the first quadrant of the coordinate system.
Signed-off-by: hrdl <51402-hrdl@users.noreply.gitlab.freedesktop.org>
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>
Fix the warning generated:
[82/243] Compiling C object libinput.so.10.13.0.p/src_evdev-tablet.c.o
../src/evdev-tablet.c:938:1: warning: unused function
'tool_set_bits_from_libwacom' [-Wunused-function]
tool_set_bits_from_libwacom(const struct tablet_dispatch *tablet,
^
When building with Clang v15 and without libwacom:
$ CC=clang CXX=clang++ meson builddir -Dlibwacom=false
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Commit 806d4a1393 ("tablet: check libevdev_get_abs_info() return
value") prevented a crash when tilt was deactivated by a quirk.
For more information check [1].
Add similar checks before calling libevdev_get_abs_info() to avoid
possible crashes.
[1] https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Commit b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
added the quirk "AttrEventCodeDisable=ABS_TILT_X;ABS_TILT_Y;" to the
Wacom 524c.
When using the pen in a display with tilt support, the tilt X/Y axes
are set as changed. Using the pen again, but this time in the display
without tilt support, will try to get the tilt information, crashing.
Check the return value of libevdev_get_abs_info() to avoid this crash.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/805
Fixes: b5f0536a4f ("quirks: add a quirk for the Wacom 524c device")
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>
A few lines north of here we return early if neither bit is set. If we
get to this point, at least one bit is set so this part of the condition
always evaluates to true.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All cases we have in our code base have an otherwise unused variable to
loop through the array. Let's auto-declare this as part of the loop.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom 524C device triggers a kernel bug in the InRange and Invert
handling. Every time BTN_TOUCH is set/unset the device also sets/unsets
BTN_TOOL_PEN even when we nominally have the eraser in proximity.
The event sequence effectively looks like this:
# on prox in
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
# on tip down
BTN_TOOL_PEN 1
BTN_TOUCH 1
-- SYN_REPORT ---
# on tip up
BTN_TOUCH 0
BTN_TOOL_PEN 0
-- SYN_REPORT ---
# on prox out
BTN_TOOL_RUBBER 1
-- SYN_REPORT ---
To work around this, bias our duplicate tool detection code towards the
eraser - if we have an eraser in-prox already and the pen goes
in-prox, ignore it and continue with the eraser. But if we have a pen
in-prox and the eraser goes in-prox as well, force a prox-out for the
pen and put the eraser in-prox.
Recording originally from
https://github.com/linuxwacom/xf86-input-wacom/issues/186Fixes#702
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/512 disables
input smoothing for AES devices. However, some AES devices produce
segmented/wobbly curves without smoothing. This change introduces an
`AttrTabletSmoothing` boolean property, which overrides the default smoothing
behavior.
See #632
Signed-off-by: Quytelda Kahja <quytelda@tamalin.org>
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>
This is merely the simple support that we use in the fallback backend as
well. It doesn't interact with touch arbitration directly but it'll be
good enough for the default use-case.
Fixes#476
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>
The Aiptek 8000U has a pressure offset above our default (%5) but no
meaningful way of detecting that. It doesn't provide distance or BTN_TOOL_PEN
either, so our heuristics can't hook onto anything. BTN_TOUCH is set by this
tablet but not at consistent pressure thresholds.
Work around this by shipping a quirk that ups it to 70. Aiptek
re-uses USB IDs because of course they do, so this applies to more than one
device. Let's see what breaks.
Fixes#462
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
