SW_MAX changed and the device_capability_nocaps_ignored test will fail on
older kernels. Change that test to use some other unhandled-by-libinput switch
code instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This used to do nothing, now at least it does the same thing as the
corresponding keyboard test. It merely tests the switch going on/off while a
touchpad is present, so short of an unexpected error message or a crash this
test doesn't actually test for any specific behavior.
Fixes#502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No effect on the test results because we never use ABS_Y anyway for multitouch
devices.
Fixes#505
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Putting an EVIOCGRAB on the device before sending those events means no-one
else sees those events - particularly upower. This means no-one else knows the
lid is on or off and thus we never blank the screen (or suspend/shut down but
those are inhibited anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Symmetrical to litest_create_context(), this allows us to store special data
in that context that we have access to during the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We test lid switch events which are independently handled by Upower. Let's
make sure nothing else can tell logind to suspend or shut down while we're
running.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the need to check whether the files were added in meson.build but
requires litest to traverse the source dir now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leaving in-place all those where we know the length of the prefix, but
replacing all those where we were calling strlen on the prefix.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we know that the tablet mode switch is bogus anyway, filter the event and
don't pass it to the caller. They won't know whether it's bogus so the only
result we get here is buggy behaviour.
This is the simplest solution here, it filters the mode switch at the lowest
level and thus the caller won't know that the tablet even has a mode switch at
all. Where the device doesn't have any other switches it'll also lose the
switch capability.
This may cause issues in some niche cases where the event node only has
that one bit and we now disabled it leaving us with a zero-event bit device.
Shouldn't matter to callers, but let's see.
Fixes#491
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The has_switch() function returns -1 if the device doesn't have the switch
capability - which is the same as "true" and how we used this so far. Fix the
checks.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a touch is labelled as palm on TOUCH_BEGIN (edge palms) we would still
feed the touch through the tap state machine. This would trigger the PALM
transition for each state, usually reducing the touch count.
When the touches were later released, the touch count was out of sync,
resulting in an error message. In the case of #488, the trigger was
a single evdev frame with three fingers down, the third of which was an edge
palm:
- touch 1 transitions from IDLE to TOUCH
- touch 2 transitions from TOUCH to TOUCH_2
- touch 3 (the palm) transitioned from TOUCH_2 back to TOUCH
That third transition is invalid, the palm hasn't been seen by the tap state
machine so it should just be ignored.
Fix this by moving making the tap state processing conditional on a touch
state other than TOUCH_BEGIN.
Fixes#488
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is merely the simple support that we use in the fallback backend as
well. It doesn't interact with touch arbitration directly but it'll be
good enough for the default use-case.
Fixes#476
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This somewhat duplicates the existing test
huion_static_btn_tool_pen_disable_quirk_on_prox_out
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the previous patches a tablet would ignore a valid proximity out sequence
where it happends after a forced prox-out. Fix this by checking the state when
we're in forced proximity out - if we have a zero tool state but a tool
updated then we did get a proximity out.
And fix the existing test to check for that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This quirk was introduced for #248 was caused by buggy input-wacom drivers,
not by actual firmware, see
https://gitlab.freedesktop.org/libinput/libinput/issues/381#note_279371
This appears to be the only tablet where this fix was needed, but we've been
playing whack-a-mole ever since to work around the various other tablets that
break with this behavior in place.
So let's revert that fix and hope there aren't any other tablets out there
(and if they are, we can probably quirk those). The revert makes the ISDV4 pen
quirk obsolete (see 9cb089f2b6), so this was
folded into this commit.
This reverts commit 4f63345b60.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This has never been supported through the stack. No device ever had the
required MOUSE_WHEEL_TILT_VERTICAL/HORIZONTAL udev property set, so
libinput never set the right axis source. Neither weston nor mutter
added the code for it. Even if we added wheel tilt for devices now, it
would break those devices. And the benefit we get from having those
separate is miniscule at best.
So let's do the long-term thing and just deprecate this axis source.
The wheel tilt mouse test device remains in the test suite, with the
udev properties set just to verify that we do indeed ignore those now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take a snapshot of the time every 10 libinput_dispatch() calls. During event
processing, check if the event timestamp is more than 10ms in the past and
warn if it is. This should provide a warning to users when the compositor is
too slow to processes events but events aren't coming in fast enough to
trigger SYN_DROPPED.
Because we check the device event time against the dispatch time we may get
warnings for multiple devices on delayed processing. This is intended, it's
good to know which devices were affected.
In the test suite we need to ignore the warning though, since we compose the
events in very specific ways it's common to exceed that threshold
(particularly when calling litest_touch_move_to).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was changed in 5e25bdfb03 but the litest
message lookup wasn't changed. Let's do that now and change to a generic
wording we can re-use for other messages.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
IMPORT really only supports == and != and for a short while udevd warned about
this before that warning was reverted again.
Where anything else is used, it falls back to ==. systemd upstream rules all
use a single = though, so let's stick with that to be consistent, even if it
is technically wrong (udevd will warn about this in debug mode).
See the long discussion in systemd upstream for details:
https://github.com/systemd/systemd/issues/14062Fixes#461
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No point in printing an interval of e.g. 2h as milliseconds, let's convert
this to something human-readable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of these may have a non-libwacom solution but let's be honest, you
shouldn't be skipping libwacom if you rely on tablets to be precise.
Fixes#436
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where fingers are down during startup we need to sync them to the known state
of the device so our slot count is correct. Otherwise, when the fingers are
lifted we will trigger the new assert for nactive_slots being less than 0.
Regression introduced in eb6ef9fe70Fixes#429
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a user releases all touches during a SYN_DROPPED and then puts more than
one finger back down before we sync, we end up with nonzero fake touches but
a zero slot count. This is caused by a wrong event sequences provided by
libevdev in that case.
This really needs to be fixed in libevdev, see
https://gitlab.freedesktop.org/libevdev/libevdev/merge_requests/19
In the meantime, put a check in to ignore that case and never reduce the slot
count to 0. It still leaves us open for some issues where 3fg gestures may
stop working if the right sequences are triggered during SYN_DROPPED but
updating libevdev will eventually make that go away too.
Fixes#422
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While buttons are down, don't let a forced proximity out happen. If the tablet
goes out of proximity normally that's fine but we don't force a proximity out.
Remains to be seen if this causes stuck buttons now on devices that rely on
the forced proximity out...
Fixes#403
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We know we should have an event here, so we might as well process it
immediately to speed the error case up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because certain things are hard to test when you have to guess whether a
tablet has forced proximity out or not. Currently unused, see future patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Problem: it's still not a 100% check because the way real udev handles the
EVDEV_ABS overrides ignores any that are set through udev properties only. So
we manually have to trigger the keyboard builtin for our test device which
can give us false positives (e.g. it wouldn't have detected #424). But still,
it'll alert us if the actual overridden values are different to what we
expect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was more useful when we installed multiple device rules but now it's only
one file anyway. Also, this drops the inadvertant double-dash
(e.g. 99-litest--Jo7Ji8.rules) which made the file name look like some
substitution was missing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a pen was forced out of proximity and an eraser came into proximity
without axis updates on the prox-in, subsequent axis updates would trigger the
pen back into proximity. This resulted in two tools in proximity at once
though the new pen never went out of proximity
This would trigger crashes in various compositors/applications, see
https://github.com/xournalpp/xournalpp/issues/1141#issuecomment-578362497
The cause was a wrong condition introduced in ffd8c71e4e. We only need to
force the pen bit on if the current tool state is currently zero and no tool
update was sent with the axis event. In our case, the tool state is nonzero
already (eraser) and we can skip this bit.
Fixes#418
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
alps.c hardcodes 5 slots in the kernel but some devices only provide 2 slots
plus BTN_TOOL_TRIPLETAP, etc. Fix this by counting active slots and when the
fake finger count exceeds the active slots but is still less than the number
of slots, adjust the slots themselves downwards.
And because the new test device messes with our slot count assumptions for the
various tests hardcode that one device to return 2 slots.
Fixes#408
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let those functions return true if they handled the event or false where they
didn't. This makes it more flexible to override touches in special cases only
and fall back to the normal litest handling otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is prep work for future devices that announce a wrong slot count. For the
tests this can be a problem if we rely on the correct slot count to decided
whether to run a test or not.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
