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>
needed for the razer blade keybard which provides multiple event nodes for
one physical device but it's hard/impossible to identify which one is the real
event node we care about.
https://bugs.freedesktop.org/show_bug.cgi?id=103156
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads that require the hysteresis do not have filtering in the firmware
and holding a finger still causes continuous cursor movements. This implies
that we get a continuous stream of events with motion data.
If the finger is on the touchpad but we don't see any motion, the finger is
stationary and the touchpad firmware does filtering. In that case, we don't
need to add a hysteresis on top.
https://bugs.freedesktop.org/show_bug.cgi?id=98839
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once the lid is closed, the keyboard event listener is set up to open the lid
for us on keyboard events. With the right sequence, we can trigger the
listener to be added to the list multiple times, triggering an assert in the
list test code (or an infinite loop in the 1.8 branch).
Conditions:
* SW_LID value 1 - sets up the keyboard listener
* keyboard event - sets lid_is_closed to false
* SW_LID value 0 - is ignored because we're already open
* SW_LID value 1 - sets up the keyboard listener again
https://bugs.freedesktop.org/show_bug.cgi?id=103298
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Our own reference may be the last one that's still alive if the context is
currently suspended (litest_suspend()). If we unref before removing it from
the path interface, we access already freed memory.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
We don't rely that the lid switch doesn't work in this test, but we always
print a few things when a device gets successfully added.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When running with -j 1 and CK_FORK=no, the log_handler_count is shared between
the tests. The log_priority tests can invoke the log handler during
libinput_unref(), so on the next day the log handler starts with a nonzero log
handler.
Fix this by always initializing it to 0 in the tests we expect it to be zero
and resetting it last.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because on some devices the keyboard is where the fingers are holding the
device when in tablet mode.
https://bugs.freedesktop.org/show_bug.cgi?id=102729
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously we only listened for events on the first one to come up, based on
the assumption that there can only be one internal keyboard. The Razer Blade
laptop keyboards come with with multiple event nodes, all looking like a
normal keyboard. The one that comes up first is one for special keys, so
typing on the internal keyboard after a lid switch does not toggle the write
state.
Fix this by allowing for up to 3 keyboard listeners for a lid switch.
https://bugs.freedesktop.org/show_bug.cgi?id=102039
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The test device initialization code was a bit of duplicated boilerplate and
required adding a reference to the devices to the 'devices' list in litest.c.
Automate this with a new TEST_DEVICE macro that adds the devices to a custom
section in the binary, then loops throught that section to get the device out.
This reduces the boilerplate for each test device to just the TEST_MACRO and
the LITEST_foo device enum entry. It also now automates the shortname of the
device.
The device's shortname was standardised in this approach as well, lowercase
and dashes only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The ...create() method returned the wrong device, so this one was never
actually used. Once we start using, we get test case failures related to the
device having BTN_foo events as well. For now, just disable those codes so we
have a keyboard with all keys and pass the tests. The rest needs better
fixing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Avoid processing an event with a time later than the earliest timer expiry. If
libinput_dispatch() isn't called frequently enough, we may have e.g. a tap
timeout happening but read a subsequent input event first. In that case we can
erroneously trigger or miss out on taps, see wrong palm detection, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
And instead disable it when we do get a proximity out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Some devices like the UC Logic WP5540U has BTN_STYLUS but not BTN_TOOL_PEN.
While a kernel bug, let's just handle these correctly anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=102570
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yay-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Could be fixed in the kernel, but these tablets are effectively abandoned and
fixing them is a one-by-one issue. Let's put the infrastructure in place to
have this fixed once for this type of device and move on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yay-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
