Yeah, it's duplication. But this way it's also separation and we can't
accidentally use the wrong struct.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Plenty of duplication there from the normal filter.c, but that also makes it
less likely to break if we adjust the other one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This also fixes a bug with the _noop function, because we casted to the wrong
struct the dpi value was garbage.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the standard approach for mice and touchpads to calculate the
acceleration based on the last two deltas, let's make that code shareable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's a fair bit of duplication of code from filter.c but it's not worth
disecting this and optimising it. The device is 5 years old now, we don't want
to touch this accel method so duplication is good here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This way we can pass them around easier without needing the whole
pointer_accelerator struct (which in theory is device-type specific). The
values relate to the calculation of the delta between trackers anyway, so
logically this is where they belong.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the X1 Yoga is in tablet mode, one capacitative touch button (windows
key, sends KEY_LEFTMETA) and two side volume buttons are accessible on the
front. The key event comes through the internal keyboard that we disabled in
tablet mode so it stops working.
Luckily the Yoga physically disables the "main" keyboard when in tablet mode,
so all we have to do is skip our code to disable the keyboard and the keys are
working again.
https://bugs.freedesktop.org/show_bug.cgi?id=103749
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is an external keyboard+touchpad but not recognised as touchpad by the
kernel so it's in mouse emulation mode. Double-taps are sent with impossibly
close timestamps and filtered out by the debouncing code. Since this isn't a
real button that can wear out anyway, let's just disable debouncing on this
device.
https://bugs.freedesktop.org/show_bug.cgi?id=105974
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we get to this point, we've already ruled out invalid arguments and this
shouldn't really fail, so let's reply with UNSUPPORTED instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
edit: Luckily there's no overlap between the users of those two flags so this
didn't trigger any bugs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch is in TOUCH_NONE, there is nothing to see here, please move along.
In the case of bug 105696, we were accessing the speed.exceeded_count of a
touch that was released previously, erroneously detecting a speed-based thumb.
The sequence was:
- touch down in slot 0, speed.exceeded_count is reset to 0
- move touch until exceeded_count is greater than our threshold
- touch up in slot 0
- touch down in slot 1 [1]
- touch down in slot 2 (more than 25mm away)
- we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as
speed-based thumb
[1] peculiar behavior only observed on this device, usually slots get re-used
at the first opportunity so having an inactive slot followed by higher slots
being used is unusual.
https://bugs.freedesktop.org/show_bug.cgi?id=105696
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
During libinput initialization a list of existing input devices is
retrieved from udev. This can lead to a situation where libinput can
end up processing un-configured devices because of the race generated
by udev events and libinput startup.
Sequence example:
weston - start
udev - device 1 added
weston - get a list of input devices
weston - process device 1 -- undefined behavior
udev - device 1 added - finalized
The problem was found because of incorrect touchscreen association
when in a dual monitor system the secondary touchscreen was
incorrectly associated with output one since udev didn't finish the
device initialization and WL_OUTPUT was missing.
To avoid this situation we skip un-configured devices during libinput
initialization, relying on udev to send events when devices are
fully configured.
Note: due to the peculiarities of udev_device_get_is_initialized(), the
input device is still processed if the call fails. If there are no udev
rules defined for the device, it will never be reported as initialized,
but this is not a problem, because all input devices handled by libinput
must have some udev properties set, therefore they always have rules.
Signed-off-by: Nandor Han <nandor.han@ge.com>
[Pekka: change log to debug, unref device]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Regression introduced by 3979b9e16a, bug 105258.
With that commit, we only ended real touches when we had less than nslots fake
fingers down. i.e. tripletap on a 2 slot touchpad would not end the
first/second touch even if the pressure goes below the threshold. e.g. Lenovo
x270 needs this, see https://bugs.freedesktop.org/attachment.cgi?id=137672, it
dips below the pressure threshold for the first slot and ends the second slot
in the same frame as the third finger is detected. Fun times.
Anyway, this breaks semi-mt touchpads, another fine category of devices,
because some of those can detect hovering fingers at low pressure, see bug
105535. Because semi-mt devices are generally garbage, we treat them as
single-touch devices instead. So whenever two fingers are down, we treat both
as above the pressure threshold, even when they're physicall hovering.
Fix this by making the x270 fix conditional on at least 2 slots.
https://bugs.freedesktop.org/show_bug.cgi?id=105535
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're left-shifting the bits but weren't comparing against the l_r_l mask
itself. So if we get a sequence of [1, 1, 0, 1] we didn't detect a wobble
because 0b1101 != 0b101 (what we're looking for).
Fix this by turning it into a right shift, that way the bits fall off
the mask automatic
al
ly
y
y
y
y
. .
_._v.___
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Otherwise a hovering touch stays around forever even after the finger has
discontinued. This doesn't matter on slots, but for fake fingers the finger
may suddenly end up being forced down/up as a result of the pressure changes
on the real fingers.
So when in maybe_end_touch, switch them back to NONE immediately - hovering
touches do not need to trigger a TOUCH_END event.
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel fuzz handling is buggy, especially when we want to rely on the fuzz
value for our hysteresis. But since this is a hw property and (at least
sometimes) set by the driver, we can't make this a pure libinput hwdb set
either.
So our workaround is:
* extract the (non-zero) fuzz into a udev property so we don't lose it
* set the fuzz to 0 to disable the in-kernel hysteresis
* overwrite our internal absinfo with the property fuzz
This way we get to use the hw-specified fuzz without having the kernel muck
around with it. We also get to use the EVDEV_ABS_ values in 60-evdev.hwdb to
override a driver-set fuzz.
Two drawbacks:
- we're resetting the kernel fuzz to 0, this affects any other users of the
device node. That's probably a minor impact only.
- we can only save this in a udev property there's a risk of this information
getting lost when playing around with udev rules. That too should be a minor
issue.
https://bugs.freedesktop.org/show_bug.cgi?id=105303
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fuzz is 0, assume we don't need hysteresis and use the wobble detection
code instead. If the fuzz is non-zero, enable it by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We currently used 0.5mm on touchpads as hysteresis value. This causes pointer
movement delays, it is likely too high. Reduce it to a kernel-set fuzz value
(if any) and see how we go with that. On many touchpads, the fuzz is 8 which
would be closer to 0.2mm on e.g. a T440.
Note that the does some defuzzing anyway, but the response of that function is
nonlinear, e.g. for a fuzz of 8, the physical deltas map to:
phys 0..3 → delta 0
phys 4..7 → delta 1
phys 8..15 → delta 4, 5, 6, 7
phys 16..N → delta 16..N
In other words, we never see some logical deltas 2 and 3. While this shouldn't
matter given the average touchpad resolution, reducing the hysteresis margin
is likely to provide some better response. We never see values 8-15 either
which could be the cause of some pointer jumps we've been seeing.
see https://bugs.freedesktop.org/show_bug.cgi?id=105303
Devices with a fuzz of 0 have the hysteresis margin reduced to 0.25mm (from
0.5mm).
https://bugs.freedesktop.org/show_bug.cgi?id=105108
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The hysteresis-returned point always differs from the current point, even if
the hysteresis kicks in. We need to compare to the hysteresis center.
And the returned point is only the new center if we exceed the margin,
otherwise the center stays as-is.
The touch_fuzz() test only succeeded for this because for the values we were
introducing jitter by, the kernel filtered out all the actual movement so
these paths weren't hit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expected the first event after TAPPED to be a finger down. If that finger
has been recognised as palm, the finger state isn't TOUCH_BEGIN so we get an
invalid state in our FSM.
libinput bug: 0: invalid tap event TAP_EVENT_PALM in state TAP_STATE_TAPPED
https://bugs.freedesktop.org/show_bug.cgi?id=105370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of wacom's tablets, notably the Bamboo series, have a non-predictable
scheme of mapping the buttons to numeric button numbers in libwacom. Since we
promise sequential button numbers, we need to have those identical to
libwacom, otherwise it's impossible to map the two together.
Most tablets have a predictable mapping, so this does not affect the majority
of devices.
For the old-style bamboos, this swaps the buttons around with the buttons
being ordered vertically top-to-bottom in libwacom.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
