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>
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>
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>
