These conditions were never triggered by our test suite, so let's tighten up
the tests to match what we expect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first event is always a device added event, skip the loops that would
paper over this. If we ever change this, the tests *should* fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The second condition was never triggered because we shouldn't get anything but
keyboard events here. Drain the initial event burst and remove the two
skipping conditions that won't happen anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I'm using semaphore CI for build testing and that only provides Ubuntu 14.04
which doesn't have libevdev 1.3 or later.
Since this is a minor workaround for an error case only, revert the commit
again and leave the handling in. Less effort than having to patch around it in
semaphore.
This reverts commit 1e0736daf3.
gcov analysis showed that none of the actual testing conditions were hit, so
the test succeeded despite not actually testing anything. Which is good,
because testing for tilt normalization isn't correct anyway, tilt is in
physical degrees,
Drop the test and replace it with a test for pressure normalization instead.
We already have a similar one to check for [0, 1] range, this new one
explicitly tests for the extents.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They weren't originally prefixed but the various tests were, but now that we
only have one test runner binary anyway, the prefix helps sorting the files
easily within e.g. gcov results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the litest_assert_empty_queue() instead of manual checking, and remove the
manual checks after the function call.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These were just there so we didn't have an unused variable warning, but
there's no reason even assigning to anything in the first place
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We used to mark dell touchpads this way but let's make this more generic.
Nothing else used the dell touchpad model flag, so we can simply replace it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This requires to expand the blacklisting to be a bit more specific so we don't
initialize dwt config on devices that won't need it.
https://bugs.freedesktop.org/show_bug.cgi?id=99140
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This should be handled by a udev rule in systemd/hwdb but that rule doesn't
apply to virtual devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
I've never had the log output help me identify a bug during a test run. Now
that we run all tests in the same binary the verbosity just leads to a massive
file that makes it hard to find the actual failure. Turn off LITEST_VERBOSE by
default but leave the parsing in for cases where it may come in handy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The Elantech touchpad on my Asus Vivobook doesn't release BTN_TOOL_FINGER on
up. If the touchpad was used before libinput initializes, the kernel filters
the event because its state is already set. We never receive it and keep
ignoring all events until the first switch to BTN_TOOL_DOUBLETAP and back.
On touchpad init sync the BTN_TOOL_FINGER state and set it accordingly. This
is the only event that can be legitimately down on init. We don't care about
BTN_TOUCH because ignoring an ongoing touch on init is generally a good idea
and we can ignore any multifinger gesture as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
In bc9f16b40e the license was updated from MIT
X11 to MIT Expat, see that commit for details.
These devices came in from the tablet-support branch which didn't get
updated, any new tablet device that used those as templated thus copied the
license. Fix this, make the license text the same as all other files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
We have one. Yay. Lucky us. Go forth and celebrate.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Move the code from the touchpad code into the more generic evdev code
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fix the kernel driver or get a udev override in place. Tablets not having a
physical size is not ok.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The hysteresis cuts the first pointer motion by the hysteresis margin. On some
touchpads this causes the tests to fail when the motion history length is
reduced (future patch). Allow the first event to be smaller than the expected
minimum.
This doesn't trigger in current tests because the hysteresis is per-event and
by the time we get past the minimum 4 events to move the pointer, we're
already flying unaffected by the hysteresis.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The test is supposed to make sure no motion event is sent and that scrolling
continues once leaving the edge. It does so by moving down the edge, into the
touchpad, then down further. The move from the edge into the touchpad had a
vertical component to it though and could cause the scroll minimum test to
fail. This is currently covered up by the delta calculations though, but fix
it anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This doesn't have an effect in our current tests because the touchpad always
needs 4 motion events to get moving. But for the future, it simplifies the
case of "i want to move between x1/y1 and x2/y2", because it fills in only the
events in between rather than re-using the touch down coordinates and thus not
causing a motion on the first event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
touchpad-tap.c: In function ‘touchpad_3fg_tap_btntool_inverted’:
touchpad-tap.c:1548:2: warning: ‘button’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
and similar
False positive, if button isn't set by now we would've abort()-ed before we
even get here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The tests require the creation of udev devices which in turn require root and
usually cause distcheck runs to fail. Add a new option to disable the
*running* of tests at distcheck (we still want to build them).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Not all mice have a click angle with integer degrees. The new
MOUSE_WHEEL_CLICK_COUNT property specifies how many clicks per full rotation,
the angle can be calculated from that.
See https://github.com/systemd/systemd/pull/4440 for more information
CLICK_COUNT overrides CLICK_ANGLE, so we check for the former first and then
fall back to the angle if need be. No changes to the user-facing API.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A joystick has ID_INPUT_JOYSTICK *and* ID_INPUT set, so we need to check for
both.
https://bugs.freedesktop.org/show_bug.cgi?id=98009
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Without the comma it now assigns the horizontal click angle property to all
devices.
Introduced in b02acd346b
Signed-off-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>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Fixes the respective clang warnings
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Some trackpoints, notably the one on the Lenovo T460s have a tendency to send
the odd event even when they're not actually used. Trackpoint events trigger
palm detection (see 0210f1fee1) and thus effectively disable the touchpad,
causing the touchpad to appear nonresponsive.
Fix this by requiring at least 3 events from a trackpoint before palm
detection is enabled. For normal use it's hard enough to trigger a single
event anyway so this should not affect the normal use-case.
https://bugzilla.redhat.com/show_bug.cgi?id=1364850
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
That's where this device comes from. The x220 is special because it's too
small to trigger some of the features, eg. palm detection. Make this more
obvious by changing to a less generic name.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So far we've relied on the wacom kernel module to do touch arbitration for us
but that won't be the case in upcoming kernels. Implement touch arbitration in
userspace by pairing the two devices and suspending the touch device whenever
a tool comes into proximity.
In the future more sophisticated arbitration can be done (e.g. only touches
which are close to the pen) but let's burn that bridge when we have to cross
it.
Note that touch arbitration is "device suspend light", i.e. we leave the
device enabled and the fd is active. Tablet interactions are comparatively
short-lived, so closing the fd and asking logind for a new one every time the
pen changes proximity is suboptimal. Instead, we just keep a boolean around
and discard all events while it is set.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Touch sequences are interrupted by TOUCH_FRAME events which makes them
annoying to handle event-by-event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
