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>
check 0.13.0 introduced a new struct type TTest for test functions
instead of just a function. However, now the tcase_add_* functions use
`const Ttest *`, and since litest stores the test case in a `void *`,
we get warnings like the following:
../test/test-touchpad.c:7079:30: warning: passing argument 3 of '_litest_add' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
litest_add("touchpad:fuzz", touchpad_fuzz, LITEST_TOUCHPAD, LITEST_ANY);
To fix this, use `const void *`, which is compatible with both APIs.
Signed-off-by: Michael Forney <mforney@mforney.org>
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libcheck has the ability to write out XML files for test results, but
converting those into junit isn't ideal, for a number of reasons:
- junit xml is different to libcheck's xml, so not all data is available or
useful. Especially with our litest wrappers around it.
- litest forking off tests means we have to wrap around everything anyway to
avoid multiple forks writing to the same test file.
This is the minimal implementation since it's only user is likely the CI which
we control fairly tightly. So there are a few corners we can skip:
- no filename validation is performed by litest
- we write out a lot of junit xml files (one per litest fork). Rather than
collating those we just rely on the CI to find the files.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A unique substring of a test/group/device should be enough to filter, even
without surrounding it with asterisks.
This allows for things like --filter-device=t440 as opposed to the previous
--filter-device="*t440*".
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In the current implementation, movements > threshold and timeouts usually move
to HOLD state and continue from there. Where a finger is lifted, we go back
up the diagram into the previous finger count's HOLD state.
The side-effect of this is that a tap of a finger can be counted as tap even
after a movement:
- two fingers down, move to scroll, hold down
- third finger down, third finger up
This sequence triggers an erroneous three-finger tap. Once the motion
threshold is hit by any touch, no finger must trigger 2/3 finger tap events
while any touch is down.
The false tap is only triggered where the new finger can execute a tap without
any other finger changing any property. This can be triggered on the
reporter's Dell Precision 5520 but on most other touchpads, a new finger down
will trigger slight movement, pressure or touch size updates and thus the bug
cannot be triggered.
Fixes#382
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The motion event here was intended to offset the light pressure from the
extended touch down. This also causes motion past the tap threshold and won't
work with a future patch.
Make the touch "real" by simply plaing a normal movement in the current
position - the kernel will filter and we'll just update the pressure.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As of d20bbfa5cb we handle the direct tool switch correctly so there's
no more warning. Which means testing for the warning is pointless.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
copy/paste error that makes coverity unhappy. This is the code to correctly
release all touches and the buttons have already been processed above - no
need to reassign here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity complains that we call libinput_event_destroy() twice on the variable
(once in and once just outside the condition). This is technically correct but
never true because we always break the loop early for the touch up/frame events.
Let's just reset the pointers so coverity is happy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
x/y assigned but never used. Dropping those few lines gets rid of the warning
and checks the coordinates correctly now too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Any touch down event will also provide motion data, but we must not send a
motion event for those in the same frame as the down event.
Fixes#375
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scrolling and gestures use unaccelerated motion. The idea behind it was that
at least for the default speed setting of 0, the accelerated speed and
unaccelerated speed are identical where meaningful.
The touchpad speed curve has a plateau for 'normal' speeds (i.e. not very slow
and not very fast) where the acceleration factor is constant. This is the
reference factor that the unaccelerated motion should use as well.
Since the touchpad acceleration rework in d6e5313497 the reference factor is
0.9 * TP_MAGIC_SLOWDOWN (previously the factor was 1.0 * TP_MAGIC_SLOWDOWN)
and scroll motion is thus 10% faster than the pointer movement at the default
speeds. Let's fix this and let the two match up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some graphics tablets (most or all Wacom, for example) do not emit
proximity out events when the tablet pen goes out of range. To
compensate for this, libinput synthesizes proximity out events when no
events are received for a certain period of time. Unfortunately, on some
tablets, this is fairly failure prone when moving the pen slowly. As a
workaround, this patch causes libinput to avoid synthesizing proximity
out events when the pen is still in contact with the tablet pad, as
defined by the TABLET_TOOL_IN_CONTACT status.
The udev_properties array is currently variable length, which causes the
tests to invoke undefined behavior on empty lists, as it attempts to
access the first array item to check if the key is NULL, which is an out
of bounds read and will fail when the struct alignment happens to line
up such that there is no padding after the list in the empty list case.
By making the udev_properties array 32 items long, it can encapsulate
every existing case, with only a fairly small amount of memory overhead,
and without requiring every single `TEST_DEVICE` call to initialize
`udev_properties`.
This used to work under valgrind up to F30 but with the F31 beta something is
now a tad slower so it triggers the timeouts before the middle emulation kicks
in.
The middlebutton timeout is 50ms and the first debounce timeout is 30ms, so if
we're late by 20ms, well, there goes the timeout.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
