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>
We haven't seen jumps on Wacom tablets yet and they cause error messages in
most of the tests. litest uses a scaling approach for most events, so a finger
move that moves from 30% to 80% of the touchpad with can easily trigger a jump
on a Wacom tablet due to its physical size.
Rather than having to fix up all tests for the larger size (and potentially
cover some other bugs) simply disable this test for Wacom tablets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This was introduced for bug 94379 - an X1 Carbon 3rd. Other touchpads have
different pressure change ranges, causing this condition to trigger
randomly and resulting in a jerky pointer motion.
For now, reduce the check to the *50 and *60 series touchpads until we have
data for more touchpads that we can add one-by-one.
https://bugs.freedesktop.org/show_bug.cgi?id=95393
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Part of C11, defined via assert.h.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Tested-by: Baruch Siach <baruch@tkos.co.il>
Trackballs are effectively stationary devices and can be positioned at any
rotation. They are also employed by users with impaired dexterity which
sometimes implies that they are positioned at an non-default angle to make the
buttons easier to reach.
Add a config option for rotation for trackball devices. Currently only
supported for 90-degree angles, if there is a need we can add more angles
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduced in 6ad303b as part of an code flow optimization, causing any 3+
finger gesture to be posted as swipe gesture, even when gestures are disabled.
However, the event is filtered in the higher levels with a bug message printed
to the log.
Don't post swipe gestures for devices where gestures are disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=95314
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
