A touchpad that was disabled by toggling the sendevents option would come back
normally after a lid resume, despite still being nominally disabled.
https://bugzilla.redhat.com/show_bug.cgi?id=1448962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leave a narrow gap so the mouse moves excruciatingly slow instead of not
moving at all. This allows to recover from overexcited mouse speed slider
movements.
https://bugs.freedesktop.org/show_bug.cgi?id=102501
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we find an EKR, search for the usb hub of the Cintiq, then find the Cintiq
Pen (or Touch) device and assume that device's product id. This way we end up
in the same device group as the Cintiq.
Co-authored-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On some devices with a tablet mode switch, the touchpad is inacessible when
in tablet mode and we don't really need this except to avoid possible ghost
touches (none have been mentioned so far). On other devices like the Lenovo
Yoga, the touchpad points to the back of the device and it's hard to use the
device without accidentally using the touchpad. For those, disabling the
touchpad is the best solution.
https://bugs.freedesktop.org/show_bug.cgi?id=102408
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was originally designed to deal with devices that only have SW_LID. But
it can be moved into the evdev interface to avoid duplication once we have
SW_TABLET_MODE. The original assumption of the lid switch device being a
standalone device with no other switches is not true, having a separate
dispatch hurts us here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
More in line with other tests and allows us to use 'sw' as name for the actual
switch to be toggled later. The variable name 'sw' stays in those tests where
we have touchpad/keyboard/etc. devices as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Calculate the speed of the touch and compare it against a fixed speed limit.
If a touch exceeds the speed when a second touch is set down, that second
touch is marked as a thumb and ignored (unless it's right next to the other
finger, then it's likely a 2fg scroll).
The speed calculation is simple but has to lag behind by one sample - we reset
the motion history whenever a new finger is set down (to avoid pointer jumps)
so we need to know if the finger was moving fast *before* this happens. Plus,
with the pointer jumps we're more likely to get false positives if we
calculate the speed on actual finger down.
This is the simplest version for now, the speed varies greatly between
movements and should probably be averaged across the last 3-or-so samples.
https://bugs.freedesktop.org/show_bug.cgi?id=99703
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Devices tagged as accelerometers may also be other devices like tablet pads.
Only ignore pure accelerometer devices but disable the accelerometer axes for
devices that have multiple types.
https://bugs.freedesktop.org/show_bug.cgi?id=102100
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The current tests worked because all rings had the same range, so our error
margin covered for that. With the upcoming MobileStudio Pro 16 pad device, the
range is half and our error margins don't work anymore. Switch to a more
reliable approach that tests every integer value the wheel can send, even
though it relies on kernel filtering.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The recommended way to have libinput ignore specific devices so far was to
remove the ID_INPUT* properties from the device. That may also affect other
pieces of the stack that need access to this device.
For the niche case of a device that should only be ignored by libinput but
otherwise be treated normally by the system, we now support the
LIBINPUT_IGNORE_DEVICE property.
If the property is set to "0", it's equivalent to being unset. This gets
around some technical limitations in udev where unsetting a property is
impossible via a hwdb entry.
https://bugs.freedesktop.org/show_bug.cgi?id=102229
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And make it init the full litest device minus the libinput device. This
enables us to add litest devices that aren't handled by libinput.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
"This gives some more sensitivity to the fingers without introducing spurious
touches and movements."
https://bugs.freedesktop.org/show_bug.cgi?id=101670
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It seems the unit tests rely on another part of <linux/input.h> which I
missed in the previous commit (5cf4b35b).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Various files use #include <linux/input.h> and, if the system input.h is
too old, will fail to compile. Use the internal copy by adding -Iinclude
to the build command lines. This was the case in the old autotools build
system.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On MBP13,3 the touch areas are quite large, and a thumb size easily gets
to 1000+. Hence need to be able to set palm sizes > 1024 (using 1200
currently).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bluetooth wreaks havoc with the timestamp of the input events coming
from the touchpad, enable timestamp smoothing support to counter this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices, specifically some bluetooth touchpads generate quite
unreliable timestamps for their events. The problem seems to be that
(some of) these touchpads sample at aprox 90 Hz, but the bluetooth stack
only communicates about every 30 ms (*) and then sends mutiple HID input
reports in one batch.
This results in 2-4 packets / SYNs every 30 ms. With timestamps really
close together. The finger coordinate deltas in these packets change by
aprox. the same amount between each packet when moving a finger at
constant speed. But the time deltas are e.g. 28 ms, 1 ms, 1 ms resulting
in calculate_tracker_velocity returning vastly different speeds for the
1st and 2nd packet, which in turn results in very "jerky" mouse pointer
movement.
*) Maybe it is waiting for a transmit time slot or some such.
This commit adds support for a real simple timestamp smoothing algorithm,
intended *only* for use with touchpads. Since touchpads will send a
contineous stream of events at their sample rate when a finger is down,
this filter simply assumes that any events which are under
event_delta_smooth_threshold us apart are part of a smooth continuous
stream of events with each event being event_delta_smooth_value us apart.
Theoritically a very still finger may send the exact same coordinates
and pressure twice, but even if this happens that is not a problem because
a still finger generates coordinates changes below the hyst treshold so
we ignore it anyways.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't know the position of the third finger on 2-slot touchpads, differing
between swipe and pinch is reliable. Simply disable 3-finger pinch and always
use swipe; 3fg pinch is uncommon anyway and it's better to have one of the
gestures working reliably than both unreliably.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The lid dispatch interface is a one-trick pony and can only handle SW_LID. It
ignores other switches but crashes on any event type other than EV_SW and
EV_SYN. Disable those types so we just ignore the event instead of asserting.
https://bugs.freedesktop.org/show_bug.cgi?id=101853
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Some devices have worn-out switches or just cheap switches that trigger
multiple button events for each press. These can be identified by unfeasably
short time deltas between the release and the next press event. In the
recordings I've seen so far, that timeout is 8ms.
We have a two-stage behavior: by default, we do not delay any events but we
monitor timestamps. The first time a bouncing button is detected we switch to
debounce mode. From then on, release events are delayed slightly to check for
subsequent button events. If one occurs, the releas and press are filtered. If
none occurs, the release event is passed to the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=100057
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a timer_func causes the removal or addition of a different timer, our tmp
pointer from the list_for_each_safe may not be valid anymore.
This was triggered by having the debounce code trigger a middle button state
change, which caused that timer to be cancelled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Race conditions may happen where code that cancels a timer is called just
as that timer triggers. If we cancel a timer, we assume that we've put the
code into a state where the timer firing will trigger a bug.
This could be observed with the middle button code if the release event was
held back just long enough. The button release code cancelled the timer, set
the state back to idle and then complained when the timeout handling sent a
'timeout' event while being in idle.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the kernel sends us a button press for a button that is thought to be down
we have lost track of the state of the button. Ignore the button press event,
in the hope that the next release makes things right again.
A release event may be masked if another process grabs the device for some
period of time, e.g. libinput debug-events --grab.
https://bugs.freedesktop.org/show_bug.cgi?id=101796
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add parsing for a LIBINPUT_ATTR_TRACKPOINT_RANGE property to enable
hardware-dependent ranges. These take precedence over the sensitivity parsing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
