udev requires callout binaries to sit in /lib/udev or otherwise provide an
absolute path. The test suite should work without installing everything first,
so create two rule files - one to install, one with the path to the
$builddir/test
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Most thumbs are detected a few events into the sequence. Work this into parts
of the tapping state machine. Only the most common use-case is handled here -
if the first finger ends up being marked as a thumb, we return to the idle
state and ignore that touch sequence.
At any other state, we handle thumbs like any other finger.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All touchpad recordings seen so far show that a value above 100 is definitely
a thumb or a palm. Values below are harder to discern, and the same isn't true
for touchpads supporting ABS_PRESSURE instead of ABS_MT_PRESSURE.
The handling of a touch is as outlined in tp_thumb_detect:
* thumbs are ignored for pointer motion
* thumbs cancel gestures
* thumbs are ignored for clickfinger count
* edge scrolling doesn't care either way
* software buttons don't care either way
* tap: only if thumb on begin
The handling of thumbs while tapping is the simplest approach only, more to
come in follow-up patches.
Note that "thumb" is the synonym for "this touch is too big to be a
fingertip". Which means that a light thumb touch will still be counted as a
finger. The side-effect here is that thumbs resting a the bottom edge of the
touchpad will almost certainly not trigger the pressure threshold because
most of the thumb is off the touchpad.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The touchpads currently all send a default value of 30 for ABS_PRESSURE. For
some tests we want to have a custom pressure but changing all tests isn't
sensible. So hook each device up to send a default value of 30 if it isn't
overridden in the test itself.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Watching a colleague try clickfinger right-click after enabling it the first
time showed that the vertical distance is too small. Increase it to 30mm
instead.
Increase the allowed spread between fingers to 40x30mm, but check if one of
the fingers is in the bottom-most 20mm of the touchpad. If that's the case,
and the touchpad is large enough to be feasable for resting a thumb on it,
discard the finger for clickfinger count.
If both fingers are in that area or one finger is in the area and they're
really close together, the fingers count separately and are not regarded as
thumb.
https://bugs.freedesktop.org/show_bug.cgi?id=91046
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes the test code easier to read. In tests where we explicitly check the API
the real calls were left in place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No functional changes, just so we can group those helpers together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Adds the macros ck_assert_double_{eq,ne,lt,gt,le,ge} to compare double
values using a fixed tolerance value. The tolerance value is
picked based on the range of values to be expected by the libinput API.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device provides a circular touch point size and and hence lacks
orientation. It will be used to test default value handling.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adds a device with various touch related axes and respective device features
to litest.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This change adds strict axis_replacement and litest_touch_move_extended
and litest_touch_down_extended to simulate changes to other axes during
touch down and move events.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For start/end, dx/dy is always 0.0, and there is no need to make calling this
function for start/end a caller bug. It just unnecessarily complicates the
caller's codepath.
Same for get_angle
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Implement touchpad pinch (and rotate) gesture support.
Note that two two-finger scrolling tests are slightly tweaked to assure that
there is enough touch movement to allow the scroll-or-pinch detect code to do
its work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Extend the touchpad gesture API with pinch gestures. Note that this
new API offers a single event stream for both pinch and rotate data, this
is deliberate as some applications may be interested in getting both at
the same time. Applications which are only interested in one or the other
can simply ignore the other.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Add support for swipe gestures.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
For touchscreens we always send raw touch events to the compositor, and the
compositor or application toolkits do gesture recognition. This makes sense
because on a touchscreen which window / widget the touches are over is
important context to know to interpret gestures.
On touchpads however we never send raw events since a touchpad is an absolute
device which primary function is to send pointer motion delta-s, so we always
need to do processing (and a lot of it) on the raw events.
Moreover there is nothing underneath the finger which influences how to
interpret gestures, and there is a lot of touchpad and libinput configuration
specific context necessary for gesture recognition. E.g. is this a clickpad,
and if so are softbuttons or clickfinger used? What is the size of the
softbuttons? Is this a true multi-touch touchpad or a semi multi-touch touchpad
which only gives us a bounding box enclosing the fingers? Etc.
So for touchpads it is better to do gesture processing in libinput, this commit
adds an initial implementation of a Gesture event API which only supports swipe
gestures, other gestures will be added later following the same model wrt,
having clear start and stop events and the number of fingers involved being
fixed once a gesture sequence starts.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
When the condition with continue was hit, syspath was still compared in the
loop condition, leading to crashes when strcmp()-ing a random string.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test doesn't really test for that because the kernel shouldn't forward
these events to us in the first place. It's merely a canary to warn us if this
ever changes and we end up not ignoring the events.
The test is only run for one device (the default mouse), no need to waste more
time on this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
