Slight disadvantage: this breaks Ctrl+C to cancel the test suite. Still
potentially better than injecting random events into your vt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If a touch is in TOUCH_NONE, there is nothing to see here, please move along.
In the case of bug 105696, we were accessing the speed.exceeded_count of a
touch that was released previously, erroneously detecting a speed-based thumb.
The sequence was:
- touch down in slot 0, speed.exceeded_count is reset to 0
- move touch until exceeded_count is greater than our threshold
- touch up in slot 0
- touch down in slot 1 [1]
- touch down in slot 2 (more than 25mm away)
- we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as
speed-based thumb
[1] peculiar behavior only observed on this device, usually slots get re-used
at the first opportunity so having an inactive slot followed by higher slots
being used is unusual.
https://bugs.freedesktop.org/show_bug.cgi?id=105696
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
An aborted test run can sometimes leave udev rules as detritus. Test for that
so we don't get test case failures triggered by those rules.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This guarantees the device rules have a static order between test runs.
Previously and in some cases, the temporary file name could affect the order
of the udev rules - let's not do that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Regression introduced by 3979b9e16a, bug 105258.
With that commit, we only ended real touches when we had less than nslots fake
fingers down. i.e. tripletap on a 2 slot touchpad would not end the
first/second touch even if the pressure goes below the threshold. e.g. Lenovo
x270 needs this, see https://bugs.freedesktop.org/attachment.cgi?id=137672, it
dips below the pressure threshold for the first slot and ends the second slot
in the same frame as the third finger is detected. Fun times.
Anyway, this breaks semi-mt touchpads, another fine category of devices,
because some of those can detect hovering fingers at low pressure, see bug
105535. Because semi-mt devices are generally garbage, we treat them as
single-touch devices instead. So whenever two fingers are down, we treat both
as above the pressure threshold, even when they're physicall hovering.
Fix this by making the x270 fix conditional on at least 2 slots.
https://bugs.freedesktop.org/show_bug.cgi?id=105535
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the cause of the random test case failures. Because the rule for this
device would also match on the Surface3 lid switch test device it comes down
to whatever mkstemps() picked as the unique characters. When the Surface3
sorted later, everything worked, otherwise it would fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having only one finger move (and the second finger at that) in semi-mt device
is not something we can realistically support. We disable the mt axes and
treat semi-mts as single-touch devices, so we don't actually get those events.
The only reason this test passed is because we release the first touch first
here, causing a ABS_X/Y shift that exceeded the motion threshold.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expected the first event after TAPPED to be a finger down. If that finger
has been recognised as palm, the finger state isn't TOUCH_BEGIN so we get an
invalid state in our FSM.
libinput bug: 0: invalid tap event TAP_EVENT_PALM in state TAP_STATE_TAPPED
https://bugs.freedesktop.org/show_bug.cgi?id=105370
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of wacom's tablets, notably the Bamboo series, have a non-predictable
scheme of mapping the buttons to numeric button numbers in libwacom. Since we
promise sequential button numbers, we need to have those identical to
libwacom, otherwise it's impossible to map the two together.
Most tablets have a predictable mapping, so this does not affect the majority
of devices.
For the old-style bamboos, this swaps the buttons around with the buttons
being ordered vertically top-to-bottom in libwacom.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
That function requires us to know which button we're testing for. Because of
the upcoming libwacom changes, we don't know which button we're about to get,
especially on the bamboos. Use the standard libinput functions to get to the
libinput event instead, we don't care about the button numbers here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This state is used by the pre-processing of the touch states to indicate that
the touch point has ended and is changed to TOUCH_END as soon as that
pre-processing is finished.
Sometimes we have to resurrect a touch point that has physically or logically
ended but needs to be kept around to keep the BTN_TOOL_* fake finger count
happy. Particularly on Synaptics touchpads, where a BTN_TOOL_TRIPLETAP can
cause a touch point to end (i.e. 1 touch down + TRIPLETAP) but that touch
restarts in the next sequence. We had a quirk for this in place already, but
if we end the touch and then re-instate it with tp_begin_touch(), we may lose
some information about thumb/palm/etc. states that touch already had. As a
result, the state machines can get confused and a touch that was previously
ignored as thumb suddenly isn't one anymore and triggers assertions.
The specific sequence in bug 10528 is:
* touch T1 down
* touch T2 down, detected as speed-based thumb, tap state machine ignores
it
* frame F: TRIPLETAP down, touch T2 up
* frame F+1: touch T2 down in next frame, but without the thumb bit
* frame F+n: touch T2 ends, tap state machine gets confused because
that touch should not trigger a release
https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we have more BTN_TOOL_*TAP fingers down than we have slots, ignore any
below-threshold pressure changes on the slots. When a touchpad only detects
two touches, guessing whether the third touch has sufficient pressure is
unreliable. Instead, always assume that all touches have sufficient pressure
when we exceed the slot number.
Exception: if all real fingers are below the pressure threshold, the fake
fingers are ignored too.
Related to https://bugs.freedesktop.org/show_bug.cgi?id=105258
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test worked because on devices that don't use pressure the touches were
reset when BTN_TOUCH when to 0, triggering the 'ignore fake fingers when no
real fingers are down' behavior. But this is a different code path than the
pressure handling, so let's separate those tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When drawing on a tablet, the hand usually rests on the device, causing touch
events. The kernel arbitrates for us in most cases, so we get a touch up
and no events while the stylus is in proximity. When lifting the hand off in a
natural position, the hand still touches the device when the pen goes out of
proximity. This is 'immediately' followed by the hand lifting off the device.
When kernel pen/touch arbitration is active, the pen proximity out causes a
touch begin for the hand still on the pad. This is followed by a touch up when
the hand lifts which happens to look exactly like a tap-to-click.
Fix this by delaying the 'arbitration is now off' toggle, causing any touch
that starts immediately after proximity out to be detected as palm and
ignored for its lifetime.
https://bugs.freedesktop.org/show_bug.cgi?id=104985
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a single-touch touchpad drops below the pressure threshold in the same
frame where a fake finger is added, we begin a fake touch here. The subsequent
loop ends this fake touch because real_fingers_down is 0.
This causes the tapping code to have a mismatch of how many fingers are down
because it never sees the touch begin event for that finger.
https://bugs.freedesktop.org/show_bug.cgi?id=105160
When the device gets deleted in a non-neutral state, we need to release all
buttons, lift the tip up and send a proximity out event.
https://bugs.freedesktop.org/show_bug.cgi?id=104940
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Aiptek tablets have the BTN_TOOL_MOUSE|LENS bits but don't actually have a
mouse, at least not in libinput (see future patches). Turns out we only have
one device that really has the tool anyway, so not running the tests for the
others seems sensible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A set of wireless devices that can scramble the timestamps, so we get
press/release within 8ms even though I doubt the user is capable of doing
this. Since they're generally good quality anyway, let's just disable
debouncing on those until someone complains and we need something more
sophisticated.
https://bugs.freedesktop.org/show_bug.cgi?id=104415
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So we don't have to have newline handling in the callers. This effectively
reverts 6ab2999be9 "test: detect linebreaks in log messages".
https://bugs.freedesktop.org/show_bug.cgi?id=104957
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If there's anything that listens for KEY_POWER it will likely shut down or
suspend the host. Since it doesn't matter whether we're really testing for
KEY_POWER or just any other key, let's just switch it and avoid one headache.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Having the system suspend or shutdown halfway through a test run is a tad
annoying. So let's talk to logind and tell it to inhibit the various keys
we're testing.
https://bugs.freedesktop.org/show_bug.cgi?id=104720
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On the very first event, the last_motion_time set by tp_begin_touch is not yet
set because we are called before the pressure-based touch detection takes
effect. And any event timestamp is more than 80ms after a zero timestamp,
causing the hysteresis to always be disabled.
https://bugs.freedesktop.org/show_bug.cgi?id=98839#c74
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running the test suite in full fork mode, the error messages are in the
quite verbose output and searching for them is annoying. Work around this by
opening a pipe to each subprocess and writing the failed test cases to that
pipe. When all tests have finished, print the messages to stdout. This way the
failures are always the last thing printed by the test suite.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some pens keep sending small amounts of pressure even when the tip is up. This
isn't always a sign of the pens worn out, it also happens on the new Pro Pen
3D models.
The X driver uses a default threshould of ~1.3% to paper over this, let's do
the same with a 1% threshold. This threshold only applies to pens that don't
already have a pressure offset anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=103086
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit db3b6fe5f7 "fallback: change to handle the state at EV_SYN time"
introduced regressions for two types of event sequences.
One is a kernel bug - some devices/drivers like the asus-wireless send a key
press + release within the same event frame which now cancels out and
disappears into the ether. This should be fixed in the kernel drivers but
there appear to be enough of them that we can't just pretend it's an outlier.
The second issue is a libinput bug. If we get two key events in the same frame
(e.g. shift + A) we update the state correctly but the events are sent in the
order of the event codes. KEY_A sorts before KEY_LEFTSHIFT and our shift + A
becomes A + shift.
Fix this by treating key events as before db3b6fe5f7 - by sending them out
as we get them.
https://bugs.freedesktop.org/show_bug.cgi?id=104030
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike the already-existing thumb detection, a touch may be labelled palm at
any time, not just during the initial touch down. This requires full
integration into the tap state machine to unwind properly. For most states, a
palm detection simply ignores the finger and reverts to the most recent state.
One exception is the case of two fingers down, one finger up followed by the
remaining finger detected as a palm finger. This triggers a single-finger tap
but with timestamps that may be from the wrong finger. Since we're within a
short tap timeout anyway this should not matter too much.
The special state PALM_UP is only handled in one condition (DEAD). Once a
touch is a palm we basically skip over it from then on. If we end up in the
DEAD state after a button press we still need to handle the palm up events
accordingly to be able to return to IDLE. That transition also requires us to
have an accurate count of the real fingers down (palms don't count) so we need
a separate nfingers_down counter for tapping.
https://bugs.freedesktop.org/show_bug.cgi?id=103210
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
8cf6893 removed it to make search/replace easier, restore it for the tests
where we don't want debouncing to automatically be handled.
Still left in place are the various top software button cases. Because of the
button re-routing through the fallback interface we need those to be
debounced.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current debouncing code monitors events and switches on when events are
too close together. From then on, any event can be delayed.
Vicente Bergas provided an algorithm that avoids most of these delays:
on a button state change we now forward the change without delay but start a
timer. If the button changes state during that timer, the changes are
ignored. On timer expiry, events are sent to match the hardware state
with the client's view of the device. This is only done if needed.
Thus, a press-release sequence of: PRP sends a single press event, a sequence of
PRPR sends press and then the release at the end of the timeout. The timeout
is short enough that the delay should not be noticeable.
This new mode is called the 'bounce' mode. The old mode is now referred to as
'spurious' mode and only covers the case of a button held down that loses
contact. It works as before, monitoring a button for these spurious contact
losses and switching on. When on, button release events are delayed as before.
The whole button debouncing moves to a state machine which makes debugging a
lot easier. See the accompanying SVG for the diagram.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is via a simple search & replace. Later auditing is needed to switch
clicks that should not be debounced (e.g. touchpads) back to a non-debounced
version.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Getting spurious test case failures in these two tests but they're not easily
reproducible. One cause may be a slight delay of the event that we're writing
to the kernel device. If that has a minor delay, we'll miss it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
