Only the cursor tool has rotation encoded as tilt, so if we don't have the
mouse tool we don't have rotation. We still need to check for ABS_Z separately
though.
Crashes Waltop tablets that have tilt x/y but no cursor/lens tool. We'd thus
never hit the rotation-z condition in tablet_check_notify_axes() and
eventually try to dereference a non-existing ABS_Z axis.
https://bugs.freedesktop.org/show_bug.cgi?id=90885
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Similar to tapping, it's a feature that is useful but confusing if a user
doesn't know it exists. It makes the touchpad appear laggy and slow to react
in the best case, or appear like a stuck button in the worst case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Leftover from the initial (out-of-tree) implementation where we updated motion
in place. That hasn't been true since libinput switched to type-safe
coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We use width/height often enough that storing it once is better than
calculating it on each event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On a touchpad without resolution, the pinned finger was stuck. The motion
distance scale factor ended up as 0 and the finger never reached the threshold
of 3mm.
int was not the best choice of datatype for a value of 0.007...
Fix the data types for xdist/ydist at the same time, clamping to int may cause
erroneous (un)pinning.
Introduced in 8025b374d5https://bugs.freedesktop.org/show_bug.cgi?id=91070
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Issues an EVIOCGRAB on the openend devices, providing exclusive access. Makes
it easier for debugging, so moving the pointer doesn't accidentally trigger
other stuff.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We need the options during open_restricted(), so instead of the caller just
passing in a custom userdata, let them wrap it into a tools_context.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When edge scrolling is triggered by exceeding the motion threshold (5mm) we
sent the whole delta as the first scroll event, causing a big jump.
Instead, send only the current delta. This effectively introduces a 5mm dead
zone when edge scrolling, still better than the jump.
https://bugs.freedesktop.org/show_bug.cgi?id=90990
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In some applications, notably Inkscape, where it is common to frequently drag
objects a short distance the default to drag-lock always-on is frustrating for
users.
Make it configurable, with the current default to "on".
New API:
libinput_device_config_tap_set_drag_lock_enabled
libinput_device_config_tap_get_drag_lock_enabled
libinput_device_config_tap_get_default_drag_lock_enabled
Any device capable of tapping is capable of drag lock, there is no explicit
availability check for drag lock. Configuration is independent, drag lock may
be enabled when tapping is disabled.
In the tests, enable/disable drag-lock explicitly where the tests depend
on it.
https://bugs.freedesktop.org/show_bug.cgi?id=90928
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional change, other than that we check for status codes now too.
In tests that don't specifically check the interface itself, a short
enable_tap() or disable_tap() is a lot more obvious to parse for the reader.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Multiple devices plugged into the same USB hub have the same
PHYS path and are assigned to the same group.
Prepend the content of the PRODUCT env to the phys path, this at least ensures
that different devices are never grouped together.
https://bugs.freedesktop.org/show_bug.cgi?id=89802
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Alps devices don't know if there is a physical middle button on the touchpad,
so they always report one.
Since a large number of touchpads only have two buttons, enable middle button
emulation by default. Those that really don't want it can play with
configuration options, everyone else has it working by default.
The hwdb entry uses "*Alps ..*" as name to also trigger the "litest Alps..."
devices.
https://bugzilla.redhat.com/show_bug.cgi?id=1227992
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Most scroll motions would be labelled a palm.
https://bugs.freedesktop.org/show_bug.cgi?id=90980
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The previous set hit _some_ sort of limit, but no idea what or why. When
adding one more test, the touchpad test case would reliably fail with a udev
timeout in litest_wait_for_udev(). This only happened in the valgrind case,
the normal run succeeded. Reproduced on three different installations (2 vms
on two different hosts).
Move the tapping tests into a separate binary, this unwedges whatever was
unhappy and sunshine, lollipops and rainbows are distributed generously.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
To quote Bryce Harrington from [1]:
"MIT has released software under several slightly different licenses,
including the old 'X11 License' or 'MIT License'. Some code under this
license was in fact included in X.org's Xserver in the past. However,
X.org now prefers the MIT Expat License as the standard (which,
confusingly, is also referred to as the 'MIT License'). See
http://cgit.freedesktop.org/xorg/xserver/tree/COPYING
When Wayland started, it was Kristian Høgsberg's intent to license it
compatibly with X.org. "I wanted Wayland to be usable (license-wise)
whereever X was usable." But, the text of the older X11 License was
taken for Wayland, rather than X11's current standard. This patch
corrects this by swapping in the intended text."
libinput is a fork of weston and thus inherited the original license intent
and the license boilerplate itself.
See this thread on wayland-devel here for a discussion:
http://lists.freedesktop.org/archives/wayland-devel/2015-May/022301.html
[1] http://lists.freedesktop.org/archives/wayland-devel/2015-June/022552.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Acked-by: Jonas Ådahl <jadahl@gmail.com>
On touchpads with resolutions, use a 5mm motion threshold before we unpin the
finger (allow motion events while a clickpad button is down). This should
remove any erroneous finger movements while clicking, at the cost of having to
move the finger a bit more for a single-finger click-and-drag (use two fingers
already!)
And drop the finger drifting, it was per-event based rather than time-based.
So unless the motion threshold was hit in a single event it was possible to
move the finger around the whole touchpad without ever unpinning it.
Drop the finger drifting altogether, if the touchpad drifts by more than 5mm
we have other issues.
https://bugzilla.redhat.com/show_bug.cgi?id=1230462
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This caused the finger to be unpinned on the first motion event after the
click, effectively disabling this feature.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Some touchpads, e.g. the Cyapa in the Acer c720 have a small axis range
([0, 870], [0, 470]), so the diagonal/magic value yields a hysteresis margin
of 1 device unit. On that device, that's one-tenth of a millimeter, causing
pointer motion just by holding the finger.
For touchpads that provide a physical resolution, set the hysteresis axes to
0.5mm and do away with the magic factor.
https://bugzilla.redhat.com/show_bug.cgi?id=1230441
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We can't rely on the system having these files installed, at least not in the
latest version that we'd like.
Copy them over from the source directory into the /run/ and /etc/ directories
for each test and update udev and the hwdb. This ensures the tags we set in
the hwdb file are always set, regardless of the system configuration.
Note that the /run/udev/* files need to have a different filename to the ones
we ship to avoid getting overridden by local configuration.
systemd does not have support for /run/udev/hwdb.d [1]. So our hwdb.d file
is in /etc/udev/hwdb.d instead and marked them with a REMOVEME and a comment
that if that file is left after the tests, it should be removed by the user.
[1] https://github.com/systemd/systemd/issues/127
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
