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>
(cherry picked from commit 1c8636923b)
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>
(cherry picked from commit ac1748ef4d)
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>
(cherry picked from commit de994d135e)
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>
(cherry picked from commit db3b6fe5f7)
So we can split up evdev-fallback.c into multiple files where needed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 87920f4992)
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>
(cherry picked from commit dc7fb65db5)
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>
(cherry picked from commit 4d7592066a)
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>
The main purpose of the edge zone is to detect palms in the area where we
cannot assume a full finger size and thus cannot use any other palm detection
mechanism. 8mm should be large enough that a finger should be detected based
on other properties (size, pressure, ...).
https://bugs.freedesktop.org/show_bug.cgi?id=103330
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The main purpose of the edge zone is to detect palms in the area where we
cannot assume a full finger size and thus cannot use any other palm detection
mechanism. 8mm should be large enough that a finger should be detected based
on other properties (size, pressure, ...).
https://bugs.freedesktop.org/show_bug.cgi?id=103330
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
If we're adding an element that's not null or not a freshly initialized list,
chances are we haven't removed it from a previous list.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
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>
Split out the fallback-specific device handling from the more generic
evdev-specific handling (which is supposed to be available for all devices).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Better for self-documentation than comments and makes it more obvious if we
initialize something wrongly.
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>
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>
A touchpad that was disabled by toggling the sendevents option would come back
normally after a lid resume, despite still being nominally disabled.
https://bugzilla.redhat.com/show_bug.cgi?id=1448962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Leave a narrow gap so the mouse moves excruciatingly slow instead of not
moving at all. This allows to recover from overexcited mouse speed slider
movements.
https://bugs.freedesktop.org/show_bug.cgi?id=102501
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we find an EKR, search for the usb hub of the Cintiq, then find the Cintiq
Pen (or Touch) device and assume that device's product id. This way we end up
in the same device group as the Cintiq.
Co-authored-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On some devices with a tablet mode switch, the touchpad is inacessible when
in tablet mode and we don't really need this except to avoid possible ghost
touches (none have been mentioned so far). On other devices like the Lenovo
Yoga, the touchpad points to the back of the device and it's hard to use the
device without accidentally using the touchpad. For those, disabling the
touchpad is the best solution.
https://bugs.freedesktop.org/show_bug.cgi?id=102408
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was originally designed to deal with devices that only have SW_LID. But
it can be moved into the evdev interface to avoid duplication once we have
SW_TABLET_MODE. The original assumption of the lid switch device being a
standalone device with no other switches is not true, having a separate
dispatch hurts us here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Calculate the speed of the touch and compare it against a fixed speed limit.
If a touch exceeds the speed when a second touch is set down, that second
touch is marked as a thumb and ignored (unless it's right next to the other
finger, then it's likely a 2fg scroll).
The speed calculation is simple but has to lag behind by one sample - we reset
the motion history whenever a new finger is set down (to avoid pointer jumps)
so we need to know if the finger was moving fast *before* this happens. Plus,
with the pointer jumps we're more likely to get false positives if we
calculate the speed on actual finger down.
This is the simplest version for now, the speed varies greatly between
movements and should probably be averaged across the last 3-or-so samples.
https://bugs.freedesktop.org/show_bug.cgi?id=99703
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
