- May 17, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- May 16, 2018
-
-
https://bugzilla.redhat.com/show_bug.cgi?id=1575260 https://bugs.freedesktop.org/show_bug.cgi?id=106489 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit d7ff5a8f)
-
Peter Hutterer authored
ALPS SS5 devices have a range above 100. https://bugs.freedesktop.org/show_bug.cgi?id=106323 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 2ca8d6cb)
-
When finger movement exceeded the motion threshold before the finger was recognized as a thumb, it would never be regarded as a thumb by the tap system. This prohibited tapping until the thumb was lifted. This is fixed by moving the check for the thumb state up such that it happens before the motion threshold check. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit af861523)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 119b6d92)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 0561f681)
-
This device frequently reports large pressure values during normal usage. It does not require a tight palm threshold, because it is a desktop device -- not built into a laptop surface -- so we can avoid false positives by setting a very high threshold. https://bugs.freedesktop.org/show_bug.cgi?id=105753 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit a1ca02ec)
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=105753 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 59eb10e5)
-
Peter Hutterer authored
Introduced in 416fa44d but there was a logic error: we claimed to require 3 events from a trackpoint before stopping the touchpad but the timer was only set when we actually stopped the touchpad. So if a trackpoint sends a single event every second, we'd disable the touchpad after 3 seconds for the duration of the timeout, then again 3 seconds later, etc. Fix this by always setting the timeout and resetting the event counter if no activity happened. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit c0fd857d)
-
- May 01, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 27, 2018
-
-
Peter Hutterer authored
This device randomly decides that a touch is now a palm, based on the moon phase, the user's starsign and possibly what the dog had for breakfast. Since libinput assumes that a touchpad that labels a touch as palm has reasons to do so, let's unassume this for this device by disabling that axis altogether and relying on the touch pressure only. https://bugzilla.redhat.com/show_bug.cgi?id=1565692 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> (cherry picked from commit 74e20e0a)
-
When the X1 Yoga is in tablet mode, one capacitative touch button (windows key, sends KEY_LEFTMETA) and two side volume buttons are accessible on the front. The key event comes through the internal keyboard that we disabled in tablet mode so it stops working. Luckily the Yoga physically disables the "main" keyboard when in tablet mode, so all we have to do is skip our code to disable the keyboard and the keys are working again. https://bugs.freedesktop.org/show_bug.cgi?id=103749 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5feaa5f0)
-
Peter Hutterer authored
On slow finger motion, this device also sends a bunch of events with only pressure updates, followed by a massive coordinate jump. Enable the quirk so we skip that jump. https://bugs.freedesktop.org/show_bug.cgi?id=105022 This patch was initially applied as ab55302e and reverted as e8cb7e45. Turns out the issues are unrelated to this patch, so let's re-apply it. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 0dccaa8a)
-
The touch size threshold was too high, so occasionally libinput would think the finger had lifted when it hadn't and events would be ignored. Similarly, the palm threshold was too low, so occasionally libinput would think a heavy single finger was a palm and ignored that too. This fixes both of those issues. https://bugs.freedesktop.org/show_bug.cgi?id=103572 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit d5b45586)
-
- Apr 19, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 18, 2018
-
-
Peter Hutterer authored
From https://bugs.freedesktop.org/show_bug.cgi?id=103947 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 93dfd0fa)
-
Peter Hutterer authored
Measured at 200 sensitivity because that's what systemd sets for us Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit cf445f99)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit f2b1eed9)
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=105485 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 9d7f48b6)
-
Signed-off-by: Sean Lanigan <sean@lano.id.au> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5aec854a)
-
- Apr 13, 2018
-
-
Peter Hutterer authored
This is an external keyboard+touchpad but not recognised as touchpad by the kernel so it's in mouse emulation mode. Double-taps are sent with impossibly close timestamps and filtered out by the debouncing code. Since this isn't a real button that can wear out anyway, let's just disable debouncing on this device. https://bugs.freedesktop.org/show_bug.cgi?id=105974 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 23614f75)
-
- Apr 09, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
If a touch is in TOUCH_NONE, there is nothing to see here, please move along. In the case of bug 105696, we were accessing the speed.exceeded_count of a touch that was released previously, erroneously detecting a speed-based thumb. The sequence was: - touch down in slot 0, speed.exceeded_count is reset to 0 - move touch until exceeded_count is greater than our threshold - touch up in slot 0 - touch down in slot 1 [1] - touch down in slot 2 (more than 25mm away) - we counted the slot 0 speed.exceeded_count, labeling the slot 2 touch as speed-based thumb [1] peculiar behavior only observed on this device, usually slots get re-used at the first opportunity so having an inactive slot followed by higher slots being used is unusual. https://bugs.freedesktop.org/show_bug.cgi?id=105696 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 928bad91)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 24963d4e)
-
Peter Hutterer authored
We currently used 0.5mm on touchpads as hysteresis value. This causes pointer movement delays, it is likely too high. Reduce it to a kernel-set fuzz value (if any) and see how we go with that. On many touchpads, the fuzz is 8 which would be closer to 0.2mm on e.g. a T440. Note that the does some defuzzing anyway, but the response of that function is nonlinear, e.g. for a fuzz of 8, the physical deltas map to: phys 0..3 → delta 0 phys 4..7 → delta 1 phys 8..15 → delta 4, 5, 6, 7 phys 16..N → delta 16..N In other words, we never see some logical deltas 2 and 3. While this shouldn't matter given the average touchpad resolution, reducing the hysteresis margin is likely to provide some better response. We never see values 8-15 either which could be the cause of some pointer jumps we've been seeing. see https://bugs.freedesktop.org/show_bug.cgi?id=105303 Devices with a fuzz of 0 have the hysteresis margin reduced to 0.25mm (from 0.5mm). https://bugs.freedesktop.org/show_bug.cgi?id=105108 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ea7498ef)
-
Peter Hutterer authored
From https://bugs.freedesktop.org/show_bug.cgi?id=105535 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 4ff5f02d)
-
Peter Hutterer authored
Tiny enough as it is, let's not take usable space away. https://bugs.freedesktop.org/show_bug.cgi?id=105434 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit d786b55d)
-
Peter Hutterer authored
click method is 'buttonareas', not just 'buttons' Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit a59ce1c0)
-
During libinput initialization a list of existing input devices is retrieved from udev. This can lead to a situation where libinput can end up processing un-configured devices because of the race generated by udev events and libinput startup. Sequence example: weston - start udev - device 1 added weston - get a list of input devices weston - process device 1 -- undefined behavior udev - device 1 added - finalized The problem was found because of incorrect touchscreen association when in a dual monitor system the secondary touchscreen was incorrectly associated with output one since udev didn't finish the device initialization and WL_OUTPUT was missing. To avoid this situation we skip un-configured devices during libinput initialization, relying on udev to send events when devices are fully configured. Note: due to the peculiarities of udev_device_get_is_initialized(), the input device is still processed if the call fails. If there are no udev rules defined for the device, it will never be reported as initialized, but this is not a problem, because all input devices handled by libinput must have some udev properties set, therefore they always have rules. Signed-off-by: Nandor Han <nandor.han@ge.com> [Pekka: change log to debug, unref device] Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 23d543b7)
-
- Apr 03, 2018
-
-
Peter Hutterer authored
Regression introduced by 3979b9e1, bug 105258. With that commit, we only ended real touches when we had less than nslots fake fingers down. i.e. tripletap on a 2 slot touchpad would not end the first/second touch even if the pressure goes below the threshold. e.g. Lenovo x270 needs this, see https://bugs.freedesktop.org/attachment.cgi?id=137672, it dips below the pressure threshold for the first slot and ends the second slot in the same frame as the third finger is detected. Fun times. Anyway, this breaks semi-mt touchpads, another fine category of devices, because some of those can detect hovering fingers at low pressure, see bug 105535. Because semi-mt devices are generally garbage, we treat them as single-touch devices instead. So whenever two fingers are down, we treat both as above the pressure threshold, even when they're physicall hovering. Fix this by making the x270 fix conditional on at least 2 slots. https://bugs.freedesktop.org/show_bug.cgi?id=105535 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 3f5ff113)
-
- Mar 14, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We're left-shifting the bits but weren't comparing against the l_r_l mask itself. So if we get a sequence of [1, 1, 0, 1] we didn't detect a wobble because 0b1101 != 0b101 (what we're looking for). Fix this by turning it into a right shift, that way the bits fall off the mask automatic al ly y y y y . . _._v.___ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5883ac7d)
-
- Mar 12, 2018
-
-
Peter Hutterer authored
Otherwise a hovering touch stays around forever even after the finger has discontinued. This doesn't matter on slots, but for fake fingers the finger may suddenly end up being forced down/up as a result of the pressure changes on the real fingers. So when in maybe_end_touch, switch them back to NONE immediately - hovering touches do not need to trigger a TOUCH_END event. https://bugs.freedesktop.org/show_bug.cgi?id=105258 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit d8db6b59)
-
- Mar 07, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
This changes the hysteresis region to an ellipse (usually a circle), where previously it was a rectangle (usually square). Using an ellipse means the algorithm is no longer more sensitive in some directions than others. It is now omnidirectional, which solves a few problems: * Moving a finger in small circles now creates circles, not squares. * Moving a finger in a curve no longer snaps the cursor to vertical or horizontal lines. The cursor now follows a similar curve to the finger. https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=105306 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 6936a155)
-
Peter Hutterer authored
This state is used by the pre-processing of the touch states to indicate that the touch point has ended and is changed to TOUCH_END as soon as that pre-processing is finished. Sometimes we have to resurrect a touch point that has physically or logically ended but needs to be kept around to keep the BTN_TOOL_* fake finger count happy. Particularly on Synaptics touchpads, where a BTN_TOOL_TRIPLETAP can cause a touch point to end (i.e. 1 touch down + TRIPLETAP) but that touch restarts in the next sequence. We had a quirk for this in place already, but if we end the touch and then re-instate it with tp_begin_touch(), we may lose some information about thumb/palm/etc. states that touch already had. As a result, the state machines can get confused and a touch that was previously ignored as thumb suddenly isn't one anymore and triggers assertions. The specific sequence in bug 10528 is: * touch T1 down * touch T2 down, detected as speed-based thumb, tap state machine ignores it * frame F: TRIPLETAP down, touch T2 up * frame F+1: touch T2 down in next frame, but without the thumb bit * frame F+n: touch T2 ends, tap state machine gets confused because that touch should not trigger a release https://bugs.freedesktop.org/show_bug.cgi?id=105258 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 6ccd8e93)
-
Peter Hutterer authored
If we have more BTN_TOOL_*TAP fingers down than we have slots, ignore any below-threshold pressure changes on the slots. When a touchpad only detects two touches, guessing whether the third touch has sufficient pressure is unreliable. Instead, always assume that all touches have sufficient pressure when we exceed the slot number. Exception: if all real fingers are below the pressure threshold, the fake fingers are ignored too. Related to https://bugs.freedesktop.org/show_bug.cgi?id=105258 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 3979b9e1)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 85e5d80c)
-
Peter Hutterer authored
Only the appletouch has pressure and thus executed that code path Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 21b83dfd)
-
Peter Hutterer authored
This test worked because on devices that don't use pressure the touches were reset when BTN_TOUCH when to 0, triggering the 'ignore fake fingers when no real fingers are down' behavior. But this is a different code path than the pressure handling, so let's separate those tests. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 990da54a)
-