Some of the 2-slot touchpads don't do gestures though (e.g. semi-mt) so skip
those.
And change the movement granularity for the pinch and spread tests so we stay
under one degree angle for lower-resolution touchpads too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit ff2ee2c681)
litest-selftest.c: In function ‘litest_ptr_eq_notrigger’:
litest-selftest.c:172:10: warning: initialization makes integer from pointer
without a cast [-Wint-conversion]
int c = NULL;
^
litest-selftest.c:173:10: warning: initialization makes integer from pointer
without a cast [-Wint-conversion]
int d = NULL;
^
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 82335b0ab9)
Synaptics, Elantech and Alps semi-mt devices all have issues with reporting
correct MT data, even the bounding box which semi-mt devices are supposed to
report is wrong.
Synaptics devices have massive jumps with two fingers down. Elantech devices
may open slots without coordinate data. Alps devices may send 0/0 coordinates
as initial slot position.
All these may be addressable with specific quirks, but the actual benefit is
largely restricted to better palm detection (though even with quirks this is
unlikely to work) and support for pinch gestures (again, lack of coordinates
makes supporting those hard anyway).
Elantech: https://bugs.freedesktop.org/show_bug.cgi?id=93583
Alps: https://bugzilla.redhat.com/show_bug.cgi?id=1295073
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 342bc51016)
More accurate representation of what we actually want to do. Plus it avoids
weird test case failures in semi-mt where we always pick the t/l and b/r
touches for the bounding box. That is the proper behavior for semi-mt, but
it's not for the tests where we expect simultaneous finger movement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit d19307f20d)
A fake MT device may have ABS_MT_POSITION_X but not Y. In this case we don't
care, because we don't handle those axes anyway.
http://bugs.freedesktop.org/show_bug.cgi?id=93474
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 988cfda42c)
Label internal keyboards through the udev hwdb and only pair the internal
(usb) Apple touchpads with those keyboards labelled as such.
https://bugs.freedesktop.org/show_bug.cgi?id=93367
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit b3f11180e3)
open_restricted() doesn't always mean 'open the fd'. When the X server uses
systemd-logind, the fd is opened once before PreInit and then kept open across
devices being disabled and enabled through the protocol.
When the device is re-enabled and libinput_path_add_device is called for the
device, we may have events pending on the fd, leaking information that we
should just ignore.
There's also the potential of inconsistent state. The kernel updates the
device state whenever it processes an event, the evdev ioctls return that
state. If events are pending, the state we see is newer than the events we
process immediately after initialization. That can lead to confusion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The file is already larger than 4k, so we ended up truncating the file for the
tests. This went unnoticed until recent additions that ended up truncating it
halfway through an assignment.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Converts two doubles to 24.8 fixed-width integers so assertions can be made with
doubles in tests
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9d96286a44)
Once we trigger diagonal scrolling, the device's scroll direction is set as
horiz+vert. From then on, both axes will be set on every subsequent scroll
event, even when the actual delta for an axis is 0.
This causes continuous scroll stop events in clients that care about these
things.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We dont' want to fill up the event queue and cause SYN_DROPPED events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If all fingers are released in the same frame, we won't be able to find the
top-most touch.
https://bugs.freedesktop.org/show_bug.cgi?id=93204
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If the test is filtered out and we never run it generates a false positive.
Though it isn't listed in the "Checks" summary this is a bit hard to tell when
you're running >700 tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
At least on the t440, this is enough to trigger correct detection between
pinch and scroll 90% of the time. Since scrolling is significantly more
prevalent than gesturing, erring on the side of scrolling at the cost of
misdetecting some gestures is acceptable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Asus RoG Gladius exposes two event nodes, one mouse, one keyboard. The
keyboard node has REL_X/Y and REL_HWHEEL on top of the various key bits and
ABS_VOLUME.
The keyboard node does not have BTN_* set, udev tags this device as a
keyboard only, not as a pointer but we still initialize the pointer caps for
it because of the wheel.
When moving this mouse, some deltas (ca "1 in every 20") are sent through the
keyboard node, causing a crash because we never initialized pointer
acceleration.
https://bugzilla.redhat.com/show_bug.cgi?id=1275407
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
tap-tap-down-move should emit 1 click + press, not 2 clicks + press
https://bugs.freedesktop.org/show_bug.cgi?id=92016
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The quartett of new config functions is:
libinput_device_config_accel_get_profiles
libinput_device_config_accel_get_profile
libinput_device_config_accel_set_profile
libinput_device_config_accel_get_default_profile
The profile defines how the pointer acceleration works, from a very high-level
perspective. Two profiles are on offer, "adaptive", the standard one we have
used so far and "flat" which is a simple multiplier of input deltas and
provides 1:1 mapping of device movement vs pointer movement.
The speed setting is on top of the profile, a speed of 0 (default) is the
equivalent to "no pointer acceleration". This is popular among gamers and
users of switchable-dpi mice.
The flat profile unnormalizes the deltas, i.e. you get what the device does
and any device below 800dpi will feel excruciatingly slow. The speed range
[-1, 1] maps into 0-200% of the speed. At 200%, a delta of 1 is translated
into a 2 pixel movement, anything higher makes it rather pointless.
The flat profile is currently available for all pointer devices but touchpads.
https://bugs.freedesktop.org/show_bug.cgi?id=89485
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If a caller has a reference to a device group when the context is destroyed,
the memory for the group is never released. Calling
libinput_device_group_unref() will release it and there are no side-effects
since the group has no back-references. It's inconsistent with the rest of
libinput though - all other resources get released on libinput_unref().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
The following sequence currently generates a right-button event:
finger 1 down
finger 2 down
finger 1 up
finger 2 held down
This is easily triggered with short scroll events. There are two issues here:
first is that the tapping code elsewhere treats any tap with a second finger
down as a left-button tap, not a right button one. So if anything, we should
generate a left button click here, not a right button click.
Arguably, generating a button click here is wrong though, it's not a very well
defined sequence and relatively difficult to trigger intentionally. So the
best solution here is to simply ignore the release event and move straight
back to state HOLD - unless the second finger is released within the timeout.
If the finger is set down again during the timeout, we move straight to
TOUCH_2_HOLD - this could eventually be interpreted as a tap, but not for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With this change auto assign events will be skipped if no replacement value
is provided. This behavior is practical when emitting mt events, as those
only contain the axis values that changed.
Signed-off-by: Andreas Pokorny <andreas.pokorny@canonical.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test is supposed to test for the timeout kicking in on edge scrolling -
if the finger is in the edge for longer than the timeout, we switch to
scrolling without requiring the motion threshold to be met first.
To emulate this, move the finger ever so slightly first to load up the motion
history, then timeout, then move. We expect a bunch of motion events with a
small delta.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Makes the code more straightforward, and we now require the devices to
have a height/width anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A device with REL_X/Y and keys gets marked only as ID_INPUT_KEY, initializes
as keyboard and then segfaults when we send x/y coordinates - pointer
acceleration never initializes.
Ignore the events and log a bug instead. This intentionally only papers over
the underlying issue, let's wait for a real device to trigger this and then
look at the correct solution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of going straight to pointer_notify_axis, go through
evdev_notify_axis() which flips the scroll direction around for us.
https://bugs.freedesktop.org/show_bug.cgi?id=91597
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The first finger is accurate, it's just the second finger that is imprecise,
so we can't handle it as a true touch. Instead, revert the device back to
being a single-touch touchpad and use the fake touch bits for second finger
handling.
Two-finger scrolling thus becomes usable though we will lose out on
other features like thumb detection. Useful scrolling trumps that though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Follow-up to eb146677e, if we disable 2fg scrolling on those touchpads we
should also disable gestures. The data doesn't magically become more useful.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Only abort on client or libinput bugs, skip over kernel bugs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
98346f6a1a added a warning about timeouts expiring before now. Those warnings
are triggered by a bunch of tests where we have events, then a timeout, then a
libinput_dispatch().
All these are bugs in the test, since we can't guarantee the order of fds (and
thus which fd the events are pulled off first) it's just lucky that they worked.
Insert the required libinput_dispatch() calls.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Add a LIBINPUT_TEST_DEVICE udev parameter to test devices created by
the test suite. When an application tries to add such a device to the
path backend or when the udev backend discovers such a device, it will
be ignored. Only the context when run via the test suite will actually
handle these devices.
Doing this will enable a user to run the libinput test suite on a system
running libinput without having the test suite devices interfering with
the actual system.
Note that X.org users running an input device driver that is not the
libinput X input driver will still need to manually configure the X
server to ignore such devices (see test/50-litest.conf).
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is to make room for more types of rules files.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In order to provide higher precision event time stamps, change the
internal time measuring from milliseconds to microseconds.
Microseconds are chosen because it is the most fine grained time stamp
we can get from evdev.
The API is extended with high precision getters whenever the given
information is available.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We currently rely on an extra millisecond being added by the filter
code to get a velocity that are small enough to not hit the max
acceleration limit. If this arbitrary millisecond is changed (for
example by changing the internal time measurment to microseconds and
adding just a microsecond instead), the velocity may change so that the
maximum or minimum acceleration is always hit.
Adding a delay to the test won't work either since it would not only rely
on ending up within the acceleration limits but there would also be an
non-deterministic actual delay causing the velocity of the movement
after the direction change to be potentially larger than the movement
in the original direction due to the actual time delta in libinput will
not always be 1ms.
To fix the test to not rely on any artificial delays in the filter code
nor any non-deterministic delays in the test, lets just test that the
direction change of the hardware events resulted in a direction change
of the libinput motion events.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
These touchpads have a terrible resolution when two fingers are down, causing
scrolling to jump around a lot. That then turns into bug reports that we can't
do much about, the data is simply garbage.
https://bugs.freedesktop.org/show_bug.cgi?id=91135
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
It's reasonable to expect a thumb (or the other hand's index finger) to click
a button while a finger is down for movement. It's less reasonable to expect
this when two fingers are interacting with the touchpad, or when two fingers
click the touchpad (even on a large touchpad that's an awkward position).
Simplify the clickfinger detection mechanism - if we have three touches down,
it's always a three-finger click. Two fingers may be a right click or a index
+ thumb click.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
