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>
Almost everything requires libudev because libinput.h pulls it in. Make this
an explicit dependency.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Sequences to trigger:
- spurious debouncing is enabled
- release a button in IS_DOWN state -> RELEASE_DELAYED
- short timeout triggers RELEASE_WAITING
If a button press now comes before the long timeout expires, we transition to
MAYBE_SPURIOUS where the long timeout may expire. In that case we should
transition to pressed state again.
Reported-by: Vicente Bergas <vicencb@gmail.com>
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>
The previous approach was to remember the last event and flush it at the right
time. The new approach is to update the device state during the frame and send
out the events at EV_SYN time.
This gives us two advantages: we are not dependent on the kernel order of how
events come in and we can process events depending on other events in the same
frame. This will come in handy later for button debouncing.
This is also the approach we have in the touchpad and tablet backends.
Two FIXMEs are left in place, the button debouncing code and the lid switch
code. Both need to be handled in future patches.
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>
A lot easier to process data in python than in C.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-By: Dima Ryazanov <dima@gmail.com>
Tested-By: Dima Ryazanov <dima@gmail.com>
This has no real effect at the moment because the fallback interface doesn't
care much about SYN_REPORT, it processes events as they come in. But it's a
bug nonetheless, the process() callback expects correct event frames.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We somewhat expect log message handlers to figure out how to prefix newlines
correctly anyway, but reducing the number of messages printed separately makes
the simple case better.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no need for a custom error message everywhere, it's better to log the
current state and the event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Works around the dnf error on the fedora docker image
"BDB1539 Build signature doesn't match environment"
https://bugzilla.redhat.com/show_bug.cgi?id=1483553
Suggested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
