We can't run this in parallel so it doesn't gain us any speed advantage. If
anything, it'll be slower because it's more setup time in between. But: meson
doesn't display the result until the test suite finished, so having this
broken up into smaller chunks means we're more likely to see a general failure
early.
And the failure should be quicker to reproduce as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All filter arguments currently force a -j1 unless otherwise specified. Change
this for --filter-group since that one is most likely invoked by some test
setup that can either add -j X or set the environment variable LITEST_JOBS as
well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ninja executes the test in the same order but we don't want to waste 5 minutes
testing other things when we have a udev rule leftover from a previous run.
Plus, this test can't be run in parallel with others, so in the worst case we
had to wait for several long-running tests to finish before this one could be
started.
To avoid all this, let's move this up to be the first check.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Alleged division by zero and use of an uninitialized variable. Both cannot
happen the way we call the tests, so let's just abort to make coverity happy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The coverity compiler can't handle 64-bit enums and since it does provide
useful data, let's switch this to #defines instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our udev callout is supposed to reset the kernel fuzz to 0 and move the value
to the LIBINPUT_FUZZ property. This is to stop the kernel from applying its
own hysteresis-like approach.
Where the kernel fuzz is nonzero, something has gone wrong with that approach.
Complain about it and set our fuzz to zero, we are in the hands of the kernel
now. If we leave our fuzz as nonzero, we'll apply our own hysteresis on top of
the kernel's and that leads to unresponsive behavior.
Fixes#313
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We generate litest-specific udev rules that contain the path to the binaries
in the builddir. But litest wasn't using those, so IMPORT would run things in
/usr/lib/udev instead. Thus any changes to those binaries generated false test
results depending on how compatible the system-installed libinput was.
This is why 410b157 passed the test suite for example.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And when that happens, skip the tests because what's happening here is that
you're running tests as root, but your X server doesn't allow root to connect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't have a hysteresis for tablet devices, so let's leave those as-is.
This may be a slight regression in behavior compared to pre-410b157e84 now the
kernel will apply the fuzz. Let's see if anyone notices, the fuzz is usually
so tiny on tablets that it shouldn't be noticable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the libwacom context failed to initialize for some reason, the database is
NULL and the refcount remains at zero. Calling unref should just work then.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we don't handle a device, don't touch it. Especially joysticks that we
don't handle and thus should not touch either.
Related to !231
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This causes a regression - the ID_INPUT_* properties are not available through
libudev within a callout, the device we get here basically has no properties.
Reverts !231
This reverts commit 410b157e84.
The previous movement was one finger still, the second finger moving. This may
cause axis events to trigger when a 2fg scroll gesture was detected. Those
axis events will stop after the gesture timeout but generate one more axis
stop event.
Make two changes here: first, move the fingers like a proper 2fg scroll
motion. And shuffle around the litest_drain_events() calls to ignore any axis
event immediately after the timeout.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test worked because no gesture was detected in the initial movement.
If that happens though, releasing one finger triggers the gesture timeout
during which we suppress events, thus failing the test. Fix this by moving,
waiting, moving - that will definitely generate an event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Second finger's x coordinate was wrong. That we didn't pick this up as pinch
is quite telling too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we're testing for this, let's not try to get it picked up as pinch
gestures. Only an issue on the wacom and magic trackpads because of their
physical size.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We only care about the third-finger data here, the movement of the first two
was just to get out of the base tap states. A timeout will do the same thing
here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
I don't think there was a specific reason for the second touch point to jump
around here either and the comment indicates it was just to avoid the
clickfinger distance trigger. So let's just move the first touchpoint.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the fingers are in the position in the current code, that's not a 3fg
click, that's a pinch. Let's use something more realistic.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test was putting both fingers down in the thumb area. That's not
representative, it's more likely that a thumb is in the area and the second
finger clicks elsewhere. So let's test for that instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These were supposed to test the thumb area, but the pressure exceeded the
threshold for most devices, thus ending up testing the palm detection instead.
Fix to use a timeout where possible, otherwise move them to the palm detection
code instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This pen has random timeouts, often when a button is pressed. This causes a
forced proximity out (and the button release) and makes the whole device a
tad unusable.
Nothing we can detect by heuristics since it looks like other devices that
don't send proximity out events. And the timeout can be quite high, the
recording in #304 has over 800ms for one sequence.
Fixes#304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where the proximity out event is delayed by the kernel, libinput would cause
an extra proxmity in-out after the forced proximity out event.
Event sequence is basically (k: kernel, l: libinput)
k: tablet axis events
l: tablet axis events
k: nothing for $proximity timer milliseconds
l: tablet proximity out
k: proximity out event
l: proximity in event
l: proximity out event
Fixes#306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
__builtin_popcount might not be available and in this case, a bitwise-and
can accomplish the same task.
Signed-off-by: Michael Forney <mforney@mforney.org>
__builtin_popcount might not be available on all compilers, so using
it requires a configure check and fallback implementation. In fact
on gcc without an -march flag, it gets compiled to a function call to
libgcc. However, we only need to test whether multiple bits are set,
and this can be done easily with a bitwise and.
Signed-off-by: Michael Forney <mforney@mforney.org>
