| Summary: | libinput loses track and completely stops responding during two-finger scrolling | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Daniel van Vugt <daniel.van.vugt> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Recording of the problem (starts somewhere around E: 11.8)
pinch-while-trying-to-scroll.txt |
||
Please run libinput debug-events --verbose and try to capture when it happens. After some basic modifications to the recording here to get the initial slot to 3 [1], I could see a GESTURE_STATE_PINCH event at +13.62s, but after that one gesture it continues back with scroll events. So all looks like it's working as expected in this recording. [1] evemu does not capture the initial slot number. doesn't usually matter but the apple driver uses slots more randomly. afaict your recording starts with the device in slot 3, so I adjusted for that. Created attachment 138919 [details]
pinch-while-trying-to-scroll.txt
Ah, you're right. It occasionally gets into GESTURE_STATE_PINCH by accident, and then can't return to GESTURE_STATE_SCROLL no matter how hard I try. You need to lift off and restart the gesture.
In another case, it's losing track of one of my fingers mid-scroll: event16 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event16 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event16 POINTER_AXIS +10.66s vert 0.00 horiz -1.11* (finger) event16 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event16 POINTER_AXIS +10.67s vert -2.27* horiz -2.69* (finger) event16 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event16 POINTER_AXIS +10.68s vert -1.94* horiz -1.27* (finger) event16 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event16 POINTER_AXIS +10.69s vert -2.59* horiz -2.69* (finger) event16 - gesture state: GESTURE_STATE_SCROLL → GESTURE_STATE_SCROLL event16 - touch-size: end touch event16 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE event16 POINTER_AXIS +10.81s vert 0.00* horiz 0.00* (finger) event16 POINTER_MOTION +10.81s -0.46/ -1.41 event16 POINTER_MOTION +10.82s -0.85/ -3.20 event16 POINTER_MOTION +10.83s -0.63/ -3.89 event16 POINTER_MOTION +10.84s -0.63/ -3.56 event16 POINTER_MOTION +10.85s -0.32/ -3.56 event16 - touch-size: begin touch event16 - thumb state: THUMB_STATE_MAYBE → THUMB_STATE_NO event16 - touch is speed-based thumb event16 - button state: from BUTTON_STATE_NONE, event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA event16 POINTER_MOTION +10.88s 0.00/ -3.56 event16 POINTER_MOTION +10.90s 0.00/ -0.97 event16 POINTER_MOTION +10.91s 0.00/ -4.19 event16 POINTER_MOTION +10.92s 0.00/ -2.59 event16 POINTER_MOTION +10.93s 0.00/ -0.97 event16 POINTER_MOTION +10.93s 0.00/ -3.56 event16 POINTER_MOTION +10.95s 0.00/ -0.97 But I'm using v1.10.4 with the old 60:40 thresholds. So that one should be fixed by bug 103572 I guess we can close this one now? The lack of reaction to pinch events isn't something libinput can fix, we rely on the callers to handle these. I'd rather keep this open. There are two unresolved issues: 1. Detecting pinches that are not pinches, and then not being able to get out of that state when it's more obviously wrong (user is trying to scroll). 2. Comment 3 triggers this bug too, and has nothing to do with pinches. I now wonder if I was incorrect to relate that to touch size thresholds. > when it's more obviously wrong (user is trying to scroll) pinch in libinput is pinch-and-rotate and thus includes the moving component with it. So it's really hard to figure out what the user intended based on the data we get from the touchpad because a pinch+move gives us the same data as a pinch+scroll. There likely are options to improve on this but so far no-one's found the time for it. > 2. Comment 3 triggers this bug too It does. In the output there we have: > event16 - touch-size: end touch So this indicates a touch threshold issue. Having said that, immediately after there's > event16 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP > to BUTTON_STATE_NONE which would indicate a released physical button. At that point it gets hard to guess what really happened. Note that I can only go on the data that the recording provides, I can't guess what you've been doing on the touchpad. So please keep any recordings/logs as simple and self-contained as possible. > event16 - button state: from BUTTON_STATE_AREA, event BUTTON_EVENT_UP
> to BUTTON_STATE_NONE
There is only one physical button (the whole clickpad) and it was certainly not pressed or released during my scrolling. So that part sounds like a bug.
Please confirm: * this is an issue with the touch size or not (by testing git master) * there are stray button events coming from the device? if so, needs a separate bug A month in needinfo, closing. It's still on my TODO list. Sorry, I haven't had time. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 138892 [details] Recording of the problem (starts somewhere around E: 11.8) libinput loses track and completely stops responding during two-finger scrolling. If I'm scrolling with the tips of two fingers, sometimes my fingers stick and skip, raising from the glass briefly. They definitely leave the touchpad for a split second. But when I put them back down, I get zero response to my scrolling. I have to stop trying, raise both fingers again and lower them again to get any response at all. This doesn't seem to be a touch size threshold problem since I was able to reproduce it even with 2:1.