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>
Devices tagged as accelerometers may also be other devices like tablet pads.
Only ignore pure accelerometer devices but disable the accelerometer axes for
devices that have multiple types.
https://bugs.freedesktop.org/show_bug.cgi?id=102100
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
The recommended way to have libinput ignore specific devices so far was to
remove the ID_INPUT* properties from the device. That may also affect other
pieces of the stack that need access to this device.
For the niche case of a device that should only be ignored by libinput but
otherwise be treated normally by the system, we now support the
LIBINPUT_IGNORE_DEVICE property.
If the property is set to "0", it's equivalent to being unset. This gets
around some technical limitations in udev where unsetting a property is
impossible via a hwdb entry.
https://bugs.freedesktop.org/show_bug.cgi?id=102229
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On MBP13,3 the touch areas are quite large, and a thumb size easily gets
to 1000+. Hence need to be able to set palm sizes > 1024 (using 1200
currently).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Bluetooth wreaks havoc with the timestamp of the input events coming
from the touchpad, enable timestamp smoothing support to counter this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some devices, specifically some bluetooth touchpads generate quite
unreliable timestamps for their events. The problem seems to be that
(some of) these touchpads sample at aprox 90 Hz, but the bluetooth stack
only communicates about every 30 ms (*) and then sends mutiple HID input
reports in one batch.
This results in 2-4 packets / SYNs every 30 ms. With timestamps really
close together. The finger coordinate deltas in these packets change by
aprox. the same amount between each packet when moving a finger at
constant speed. But the time deltas are e.g. 28 ms, 1 ms, 1 ms resulting
in calculate_tracker_velocity returning vastly different speeds for the
1st and 2nd packet, which in turn results in very "jerky" mouse pointer
movement.
*) Maybe it is waiting for a transmit time slot or some such.
This commit adds support for a real simple timestamp smoothing algorithm,
intended *only* for use with touchpads. Since touchpads will send a
contineous stream of events at their sample rate when a finger is down,
this filter simply assumes that any events which are under
event_delta_smooth_threshold us apart are part of a smooth continuous
stream of events with each event being event_delta_smooth_value us apart.
Theoritically a very still finger may send the exact same coordinates
and pressure twice, but even if this happens that is not a problem because
a still finger generates coordinates changes below the hyst treshold so
we ignore it anyways.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
