- 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)
-
https://bugs.freedesktop.org/show_bug.cgi?id=103572 Signed-off-by: Mario Di Raimondo <mario.diraimondo@gmail.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit f47eb2d7)
-
- Mar 02, 2018
-
-
The details are explained in comment in the code. That aside, I shall mention the check is so light, that it shouldn't influence CPU performance even a bit, and can blindly be kept always enabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104828 Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> (cherry picked from commit 400aadd5)
-
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> (cherry picked from commit e8dffbd7)
-
Peter Hutterer authored
Prep work for the wobbling detection patch Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> (cherry picked from commit e43bd4ae)
-
Peter Hutterer authored
Because life is too short for this https://bugs.freedesktop.org/show_bug.cgi?id=105265 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 39b80608)
-
Peter Hutterer authored
The sd-bus interface we're using wasn't public until 221. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 8353eeb5)
-
- Feb 28, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 27, 2018
-
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=105264 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5b29be39)
-
Peter Hutterer authored
Missing '+' in the optstring caused it to evaluate all options. If any argument was passed to a subcommand, libinput-measure would throw an error and exit. https://bugs.freedesktop.org/show_bug.cgi?id=105246 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 59550ed2)
-
Peter Hutterer authored
If a single-touch touchpad drops below the pressure threshold in the same frame where a fake finger is added, we begin a fake touch here. The subsequent loop ends this fake touch because real_fingers_down is 0. This causes the tapping code to have a mismatch of how many fingers are down because it never sees the touch begin event for that finger. https://bugs.freedesktop.org/show_bug.cgi?id=105160 (cherry picked from commit 01a633b6)
-
Tweak this python scripts to use '/usr/bin/env python3' Signed-off-by: Maxin B. John <maxin.john@intel.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 920debff)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 63880d6e)
-
If libdir is an absolute path (which means it’s outside of prefix) we would wrongly add the prefix to it in the install script. Just pass the correct libdir from Meson directly thanks to join_paths() magic. Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit b2b5cdaf)
-
Since the install script cannot know the correct bindir, just pass it from Meson directly. Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 0843fa8e)
-
Peter Hutterer authored
A set of wireless devices that can scramble the timestamps, so we get press/release within 8ms even though I doubt the user is capable of doing this. Since they're generally good quality anyway, let's just disable debouncing on those until someone complains and we need something more sophisticated. https://bugs.freedesktop.org/show_bug.cgi?id=104415 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 3a3fd645)
-
Peter Hutterer authored
https://bugzilla.redhat.com/show_bug.cgi?id=1536633 https://bugzilla.redhat.com/show_bug.cgi?id=1539046 https://bugzilla.redhat.com/show_bug.cgi?id=1539783 https://bugzilla.redhat.com/show_bug.cgi?id=1540662 https://bugs.freedesktop.org/show_bug.cgi?id=104278 Debugged-by: Jeff Smith <whydoubt@gmail.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit cb186abc)
-
- Feb 13, 2018
-
-
Peter Hutterer authored
-
- Feb 09, 2018
-
-
Peter Hutterer authored
Rotation on a tool can either ABS_Z or in the case of the mouse/lens tools a combination of ABS_TILT_X/Y. The code assumes that if the rotation on a stylus (not mouse/lense) changes, we need to fetch it from ABS_Z. This happens on the very first event from the tablet, proximity in invalidates all axes so we can send the current state to the caller. On libwacom-recognized tablets we never set the rotation bit on the stylus, so that's all fine. On tablets without libwacom support, the stylus may have a rotation bit copied because we have it set thanks to mouse+tilt on the tablet. When that first event is handled, we try to access ABS_Z. On tablets without ABS_Z like Aipteks, we go boom. Fix this by checking for ABS_Z during tablet init, if we don't have that axis then never set the rotation bit on the tool. That's the only axis where we need this, all other axes have a single cause only and thus the tablet bits are accurate anyway. https://bugs.freedesktop.org/show_bug.cgi?id=104939 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Feb 07, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We filter BTN_TOUCH in the caller, so this cannot happen here. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We fall through to the default statement anyway Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-