Increase the mm move threshold for 3 and 4 finger gestures to 2 and 3 mm,
respectively. In multi-finger gestures it's common to have minor movement
while all fingers are being put down or before the conscious movement starts.
This can trigger invalid gesture detection (e.g. a pinch instead of a swipe).
Increase the movement threshold to make sure we have sufficient input data.
No changes to 2-finger movements.
https://bugs.freedesktop.org/show_bug.cgi?id=96687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A natural hand position for a 4-finger swipe will have one finger well below
the other triggering the pinch detection. This is obviously wrong, only do the
finger position analysis when we have 2 fingers.
This is only a partial fix, for 3-4 finger gestures chances are high that the
third/fourth finger come in a different event frame. Before that we likely
detect 2 fingers in a possible pinch position and still trigger the code path.
This issue has to be fixed separately.
https://bugs.freedesktop.org/show_bug.cgi?id=96687
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current code tried to emulate the relative motion to be equivalent to the
absolute motion, except in screen coordinates. This is way too slow for the
cursor tool that we want to behave like a mouse.
Tablets have high resolution (e.g. an Intuos 4 is a 5080dpi mouse) and that
motion is way too fast to be usable. Scale it down to match a 1000dpi device
instead. Since the cursor and lens tool are still high precision devices leave
them in a flat acceleration profile without actual acceleration.
For the stylus-like devices leave the current accel, pointer acceleration on a
stylus is hard to handle.
This also adds the missing bits for actually using the speed factor set
through the config interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
The x/y tilt angle comes in as degrees, so our scale could be as large as 90x
the original size. Scale to something more sensible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The removal of the hysteresis even on precise touchpads has led to
difficulties controlling the cursor in a few instances. Since 27078b2667
we only have the hysteresis on Apple touchpads and the Lenovo *40 series and
later. Even on those do we see some positioning difficulties (bug 94379).
So restore the hysteresis by default again for all touchpads. In the future a
knob could be exposed for precision vs reactivity or something, but for now
the drawback of imprecise positioning does not outweigh the benefits we get
on those few devices.
https://bugs.freedesktop.org/show_bug.cgi?id=94379
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We will reinstate the hysteresis for all devices making the negative
pressure check unncessary.
This reverts commit ef48c07a96.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We will reinstate the hysteresis for all devices making the negative pressure
check unncessary and thus this commit as well.
This reverts commit 2f5231cc88.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This device has a touchpad on the mouse but it's labeled as mouse. For litest
we only label it as LITEST_MOUSE feature and test the touchpad directly on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Otherwise the abs->value could lie outside the [min, max] range of the axis.
This isn't much of an issue for actual axes but in the case of ABS_MT_SLOT
(value 47) it causes errors when libevdev sanitises the event into the allowed
slot range.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This avoids accidental palm detection during two-finger scrolling if one
finger is inside the edge exclusion zone.
Palm detection is designed to avoid accidental touches while typing. If a
non-palm finger is on the touchpad already the user is unlikely to be typing.
So stop palm detection in this case and process the fingers as normal.
This implementation has a minor bug: if both palm touches start within the
palm exclusion zone within the same frame, neither will be labelled as palm
due to how we check the other touches. Since this is an extremeley niche case
we can live with that.
https://bugs.freedesktop.org/show_bug.cgi?id=95417
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These devices are all over the place anyway, no need to spam the log, just
silently discard the jumps.
https://bugs.freedesktop.org/show_bug.cgi?id=96275
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And change the various callers, especially those where we only had the
separate struct for indentation purposes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The hwdb doesn't allow unsetting a property so once we start nesting model
flags it'll become important to be able to be able to unset one as well (by
assigning it to 0).
So rather than checking for existence, check whether the property is actually
set to something resembling a boolean.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This is only set on button events so use the same approach as for rings and
strips. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
A large part of the bugs seen right now are related to touchpads jittering too
much. Fixing them one by one is entertaining, but time consuming. Right now
the number of touchpads that require a hysteresis seem to outnumber those that
don't, so switch the approach around: leave the hysteresis in place but
disable it for those touchpads that don't need it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No effect so far because the dist-hook prevents us from making a tarball
without the sources anyway. But for correctness split the two up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Quite a few bugs are caused by touchpad ranges being out of whack. If we get
input events significantly outside the expected range (5% width/height as
error margin) print a warning to the log.
And add a new doc page to explain what is happening and how to fix it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No need to handle events properly in the edge scroll state machine when it's
not enabled. Just set any beginning touch to state AREA and move on. The rest
of the code guarantees neutral state when edge scrolling is enabled or
disabled.
This reduces the debug output produced by libinput-debug-events when edge
scrolling is disabled, preventing users from seemingly identifying
bugs where there are none.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Make sure that the tool is valid while the event is valid, even if the device
gets destroyed before the event is destroyed.
This cannot actually be triggered right now, the event has a ref to the device
and the tools do not get removed until the device is destroyed. But for future
implementations (e.g. where the tool is otherwise automatically destroyed on
proximity out) we need to ensure the tool remains valid for the event
lifetime.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom Express Key Remote sends the serial number via EV_MSC. At some later
point we'll need the serial to match the LEDs correctly but for now we can
ignore them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Was only used for the touchpad hysteresis, we can re-use the wobbly touchpad
tag for this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Includes the Dell Lattitude E5420 but since all alps touchpads with the same
fw version are the same (as far as we know) hooking this off the firmware
version should cover this generation.
https://bugzilla.redhat.com/show_bug.cgi?id=1336084
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If we have libevdev 1.5 or later, the resolution is already set, no need to
change it again. Let's rely on libevdev to do the right thing and simply skip
the rest if we have one correct nonzero resolution already set on the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
