On a touchpad without gestures we would take a 2-finger touch as
immediate start to a 2-finger scroll gesture. This effectively removes
the 1mm threshold we otherwise have before scrolling is assumed to have
started.
If tapping is enabled and a user triggers a small motion event this
results in scroll events being sent before the two-finger tap.
Closes#981
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/982>
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>
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.
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.
Due to a patch pushed accidentally to main, the `key_count` variable is
uninitialized in the `evdev_log_bug_libinput` code path:
../src/evdev.c:148:12: error: ‘key_count’ may be used uninitialized [-Werror=maybe-uninitialized]
148 | if (key_count > 32) {
| ^
../src/evdev.c: In function ‘evdev_pointer_post_button’:
../src/evdev.c:132:13: note: ‘key_count’ was declared here
132 | int key_count;
| ^~~~~~~~~
Fixes commit bb1e4a493f ("evdev: Log bug when releasing key with count 0")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
libinput keeps an internal key count. It is increased by 1 when the key
is pressed and decreased by one when the key is released.
The count should never be negative, however a user found an issue while
running Sway and hit an assert.
Replace the assert with a log to avoid the crash.
Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/928
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
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>
Sprinkle a few asserts into the various string helpers for where our
arguments must not be NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
For a device used upside-down, make sure the wheels correspond to the
new physical directions. There's a grace range of 20 degrees either way
since that seems like it makes sense.
For 90 degree rotation (or 270 degree) the wheel is left as-is, the
heuristics to guess what angle we want in this case is not clear enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some touchpads, notably those on the Dell XPS 15 9500, are prone to registering
touchpad clicks when the case is sufficiently flexed. Ignore these by
disregarding any clicks that are registered without touchpad touch.
Signed-off-by: Rob Glossop <robgssp@gmail.com>
This hurts more than it helps, and users complain of dead trackpad
edges. Apple touchpads have fairly sophisticated internal palm rejection
algorithms going back many years, so let's just disable this one on
everything Apple.
Related to: #433 (need to figure out what other hardware may need this)
Signed-off-by: Hector Martin <marcan@marcan.st>
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>
The key_count array for buttons records the logical button sent to the
client - for left-handed configurations that means a BTN_LEFT is
recorded as BTN_RIGHT.
When the device is suspended and we are releasing all keys we must thus
release the button code as-is without trying to map it again.
Fixes#881
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Like in libinput_device_switch_has_switch()'s documentation, document
the error case in libinput_device_tablet_pad_get_num_buttons(),
libinput_device_tablet_pad_get_num_rings() and
libinput_device_tablet_pad_get_num_strips().
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Adds a dedicated scroll movement type to the custom acceleration profile.
Supported by physical mouse and touchpad.
Other profiles remain the same by using the same unaccelerated filter for the scroll filter.
Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
The `speed_factor()` formula is unnecessarily complex, The behavior that is described in the comment can be achieved with a simple power function.
And adjust the comment to explicitly state that 0.05 is the minimum.
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>
