Since 69449ca854, the minimum deceleration is 0.3 and we don't get a 0 motion
event anymore. We can drop the helper function now too.
What we do in that test instead is pump one relative motion event through
before we start comparing the events, this way our second, third, .. events
will have some acceleration applied and the tests compare more accurate
values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We can't easily test for DMI matches, but anything that hooks onto pid/vid is
easy to verify for correctness.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Drop the busy loop we had waiting for an event to appear and just call poll on
the libinput fd.
This actually makes the tests more correct, if we now time out where we didn't
before it means we're not setting the timers correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
3s is too easy to hit on congested systems. 10s is overkill, but it's still
better to pass a test late than having to restart the whole test-suite again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Set up a udev_monitor before each device creation and wait for the monitor to
notify us of the newly created device. This should take the place of the
various sleep loops we currently have sprinkled around the code and provide a
reliability when testing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Motion normalization does not work well for devices below the default 1000dpi
rate. A 400dpi mouse's minimum movement generates a 2.5 normalized motion,
causing it to skip pixels at low speeds even when unaccelerated.
Likewise, we don't want 1000dpi mice to be normalized to a 400dpi mouse, it
feels sluggish even at higher acceleration speeds.
Instead, add a custom acceleration method for lower-dpi mice. At low-speeds,
one device unit results in a one-pixel movement. Depending on the DPI factor,
the acceleration kicks in earlier and goes to higher acceleration so faster
movements with a low-dpi mouse feel approximately the same as the same
movement on a higher-dpi mouse.
https://bugzilla.redhat.com/show_bug.cgi?id=1231304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Currently unused, but store the ratio of DPI:default DPI for later use.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This simply doesn't work for low-dpi mice. Normalizing a 400dpi mouse to a
1000dpi mouse forces a minimum movement of 2.5 units and the resulting pixel
jumps. It is impossible for the caller to detect whether the jump was caused
by a single motion or multiple motion events.
This is technically an API break, but not really.
The accelerated data was already relatively meaningless, even if normalized as
the data did not correspond predictably to any input motion (unless you know
the implementation acceleration function in the caller). So we can drop the
mention from there without expecting any ill effects in the caller.
The unaccelerated data was useless for low-dpi mice and could only be used to
measure the physical distance of the mouse movement - something not used in
any caller we're aware of (if needed, we can add that functionality as a
separate call). Dropping motion normalization for unaccelerated deltas also
restores true dpi capabilities to users of that API, mostly games that want to
make use of high-dpi mice.
This is a simplified patch, the normalization is still in place for most of
libinput, it merely carries the original coordinates in the event itself.
In the case of touchpads, the coordinates are unnormalized into the x-axis
coordinate space as per the documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Deceleration at low speeds is intended to enhance precision when moving the
pointer slowly. However, the adaptive deceleration we used was badly
calibrated, at slow-but-normal speeds the pointer became too slow to manouver.
We don't want to drop deceleration completely, the subpixel precision it
provides is useful. And it also helps those that can't move a 1000dpi mouse by
exactly one unit.
Make the adaptive deceleration steeper so it only kicks in at extremely slow
motions and defaults to 1 at anything resembling normal movement (i.e. pointer
moves like the physical device does).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested on three laptops here, Lenovo T61, X220 and an HP EliteBook (?), all
with small touchpads. It's hard to have a hand position where the palm touches
the touchpad while using the trackpoint. So we might as well save us the
effort of monitoring events and enabling/disabling it on demand.
As a side-effect this fixes 1233844, but that's more a coincidence.
https://bugzilla.redhat.com/show_bug.cgi?id=1233844
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpad is disabled for 500ms after a trackpoint event to avoid
erroneous palm touches. This is currently refreshed on every trackpoint event
and thus forces a delay of 500ms when switching between the two.
Instead, reduce the timeout to 300ms but ignore any touches started while the
trackpoint was active (i.e. before the last trackpoint event). A touch started
after the last event is released once the timeout expires.
This is the same logic used for disable-while-typing.
https://bugzilla.redhat.com/show_bug.cgi?id=1233844
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We will use this outside of DWT, so set it unconditionally on touch begin.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes, just rearranging where it fits better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Hitting this limit too often on congested VMs, so let's increase the sleep
sleep (so the system can get done what needs to be done) and get the whole
timeout from 600ms to 2000ms.
Note: if we really hit 2000ms we may still fail on some tests with the check's
default 3 second timeout.
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>
