Not all touchpad kernel drivers supply the x/y resolution. Let the udev hwdb
fix this up where possible and read the value from it.
This is intentionally only used on touchpads, touchscreen devices without
resolution should be considered buggy and fixed in the kernel.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Make the helper function accessible from other places (will be needed in an
upcoming patchset). This also now takes a custom resolution as argument
instead of always setting it to 1, and allows overriding a fake resolution
after the fact.
And instead of a hardcoded 1 everywhere, use a define for the resolution.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This way the unaccelerated deltas returned by libinput are correct.
To maintain the current behavior we slow down the input speed by the magic
factor and likewise the accelerated output speed. This produces virtually the
same accelerated deltas as the previous code.
The magic factor is applied to the default denominator for guessing a
resolution based on the touchpad diagonal. We can't really get around this
without having a resolution from the touchpad; meanwhile this produces
virtually the same coordinates before/after.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We really don't need to deal with devices that have x but not y or vice versa.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These devices don't provide ABS_X/Y, but do have proper multitouch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The struct evdev_device's absinfo_x/y point to the right axis
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Make it clear where we're dealing with device coordinates and where we're
dealing with DPI-normalized coordinates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Everywhere else in the touchpad code we use "t" for the struct tp_touch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The helper function now prints an error message if the event type passed is
not allowed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't actually use TOUCH_CANCEL in libinput, but either way calling the
slot on a cancel should be valid. Calling it on a FRAME event is not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The current default start location for the 2fg scroll tests: 47%, 50% and
53%, 50% are further than 3cm apart on the wacom-intuos-finger test device,
causing test failures when pinch gesture support gets added.
This fixes this, and also switches the fingers in the
touchpad_2fg_scroll_slow_distance and touchpad_trackpoint_buttons_2fg_scroll
tests to the default locations rather than putting them pretty far apart.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently all the touchpad 2fg tests move the 2 fingers 1 at a time,
causing a finger motion which looks more like a pinch zoom in followed by
a zoom out than an actual 2fg scroll gesture. Add a helper function which
can move 2 fingers at the same time (more or less), and use this where
relevant.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently touchpad_2fg_scroll_slow_distance always moves the touches 10% of
the touchpad height during the test.
On the wacom-intuos-finger test device this is a much larger distance then on
the synaptics test device, triggering ck_assert(axisval < 5.0) errors with
further patches in this set, this commit fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that we've separate handling of the EDGE_NEW vs EDGE states in
tp_edge_scroll_post_events() we can drop the threshold variable, in EDGE_NEW
we always want to check against DEFAULT_SCROLL_THRESHOLD and in the EDGE
state we only want to make sure that the delta != 0.0 which is already
checked later on in tp_edge_scroll_post_events().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous setting of 10 wasn't 10 mm, it was used against the deltas
normalized to a 1000DPI mouse, i.e. closer to 4mm. It was also also per-event,
so a slow movement or a high-frequency touchpad can struggle to meet the
threshold.
Change the trigger to be ~5 mm from the initial touch down, accumulated until
we either meet the threshold or the timeout expires. The first scroll event
includes the delta since the touch down rather than the most recent delta.
This removes the delay otherwise seen in scrolling and makes the scroll motion
match the finger motion. This accumulated delta only applies when exceeding
the motion threshold, when the timeout triggers the switch to scrolling the
first delta posted is the current delta.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Previous code used a device coordinate threshold of 300 which won't work on
Elantech touchpads (1280 vs the ~4000 that synaptics has).
Convert to normalized DPI and reduce the threshold to 3mm.
https://bugs.freedesktop.org/show_bug.cgi?id=89206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Ideally we want to specify various thresholds in mm, but not all touchpads
set the hardware resolutions. Rather than conditions to check for resolutions
everywhere, use a macro to give us a normalized value that we use for motion
as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
All callers except the tap motion threshold call
tp_get_delta() followed by tp_filter_motion() - the latter normalized it
before calling into the accleration code.
Move the normalization into tp_get_delta() so we don't deal with
device-specific coordinates but normalized deltas instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
On a semi-mt device lifting slot 0 before slot 1 makes slots 1 become slot 0
(with the matching coordinate jump), potentially triggering the tap movement
threshold.
On one test we can just swap the release order, the other test we need to
disable (the _inverted version of this test tests the other order anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And merge all current API versions into the same block. This isn't technically
necessary since removing libinput_has_button from the code will remove it from
the exported list. That trips up test/symbols-leak-test though.
Since we break the API and bump the soname in this release anyway, move
to a single block so the initial stable API is all nicely grouped together.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This affects the touch device on graphics tablets.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Clickpads have BTN_LEFT but no BTN_RIGHT, non-clickpads must have both.
Tablet touch devices don't have any buttons, so skip the warning for those.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Works as a touchpad but has no buttons.
Minor change to one of the touchpad tests: because the touch area is so big
the slow-scrolling trigger needs to be adjusted.
And because the device is an external device, the "disable on external mouse"
test needs to be adjusted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
These tests make sure we don't get tapping events in certain situations
(finger movement, timeouts, ...). Tapping must be enabled for that to be a
valid test.
The tests can't work on semi-mt devices because we can't end slots
independently. Disable the tests there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If we send BTN_LEFT or similar, we need the LITEST_BUTTON capability on the
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Split out into a btntool test and a true three-finger test. For consistency,
check the number of slots on all those tests rather than having
litest-device-specific exclusions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
No effect, all devices currently have tapping disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The event sequences we use for plam detection trigger tap events if enabled by
default. Always disable tapping, a set of tests for tapping in the palm
exclusion zones. Arguably, tapping in the zones should be handled in a
separate set of tests though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
