| Summary: | Two finger scroll stuck/not happening | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | eyenseo |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | peter.hutterer |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | evemu recording | ||
Today I can't reproduce this behaviour anymore - I changed nothing. Since I tested the different kernels and libinput versions I had to do reboots - is it possible that a reboot doesn't 'reset' the hardware? Today it happened again. I can't reproduce it reliably but it definitely wasn't a one off occurrence. libinput 1.10.2-1 Best to run sudo libinput debug-events --verbose and check its output, it prints when touches begin/end and what state the various features are in. There are two possible sources for this bug - the kernel/hardware or touch pressure detection. If you notice that a touch doesn't end when you release the finger, chances are it's the kernel. But this is definitely something where you have to look at the output and figure out what's going on. This is the part where the 'finger' wasn't released. I'm using my mouse, not the touchpad, and it's also not the scrolling that is the problem but a click. What happened here is that I was clicking on a image link (while moving the mouse) in chromium but instead of registering a click only the push down was registered - continuing at the end of this log part I was "dragging" the image around, without holding any mouse button. To reproduce this behaviour it is important to klick and move at the same time (1 out of ~20 tries behaves this way). The scroll issue did also occur in the terminal so chromium is possibly not the issue. ... event15 POINTER_MOTION +377.87s 1.00/ -1.00 event15 POINTER_MOTION +377.88s 2.00/ -1.00 event15 POINTER_MOTION +377.89s 0.00/ -1.00 event15 POINTER_MOTION +377.89s 0.00/ -1.00 event15 POINTER_MOTION +377.90s 1.00/ -1.00 event15 POINTER_MOTION +377.93s 0.00/ -1.00 event15 POINTER_MOTION +377.95s 1.00/ 0.00 event15 - debounce state: DEBOUNCE_STATE_IS_UP → DEBOUNCE_EVENT_PRESS → DEBOUNCE_STATE_DOWN_WAITING event15 POINTER_BUTTON +378.03s BTN_LEFT (272) pressed, seat count: 1 event15 - debounce state: DEBOUNCE_STATE_DOWN_WAITING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_DOWN event15 POINTER_MOTION +378.08s 0.00/ -1.00 event15 POINTER_MOTION +378.09s 1.00/ -2.00 event15 - debounce state: DEBOUNCE_STATE_IS_DOWN → DEBOUNCE_EVENT_RELEASE → DEBOUNCE_STATE_RELEASE_WAITING event15 POINTER_MOTION +378.10s 2.00/ -2.00 event15 POINTER_BUTTON +378.10s BTN_LEFT (272) released, seat count: 0 event15 POINTER_MOTION +378.10s 1.00/ -1.00 event15 - debounce state: DEBOUNCE_STATE_RELEASE_WAITING → DEBOUNCE_EVENT_TIMEOUT_SHORT → DEBOUNCE_STATE_RELEASED event15 POINTER_MOTION +378.11s 1.00/ -1.00 event15 - debounce state: DEBOUNCE_STATE_RELEASED → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_UP event15 POINTER_MOTION +378.12s 0.00/ -1.00 event15 POINTER_MOTION +378.13s 0.00/ -1.00 event15 POINTER_MOTION +378.14s 0.99/ 0.00 event15 POINTER_MOTION +378.14s 1.99/ -1.99 event15 POINTER_MOTION +378.15s 2.00/ -2.00 ... in libinput, touchpads and mice are completely separate so please let's not mix the two issues. If it is a libinput bug, it cannot be the same because there's virtually no overlapping code. The debug log here shows that the button state is correct, you get a press followed by a release event, the seat count is correct too. So if that triggered a stuck button, the issue is in the compositor or on the client side. But either way, this needs a separate bug report please. Needinfo for too long, closing This behaviour didn't happen again so I couldn't provide more information. I'll reopen it if it happens again and I have output from libinput debug-events --verbose. |
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 137358 [details] evemu recording I noticed today that there is a issue with two finger scrolling. "Sometimes" I start to scroll with two fingers and nothing happens. If I then use only one finger (either by lifting one or lifting both and then touching only with one again) I will scroll. The only way to 'unstuck' the scrolling is to click. I am not sure which version introduced this behavior and I wasn't able to playback the recording. Further I'm not sure if this is indeed a bug in libinput or was introduced by the kernel but since the debug output showed what I was experiencing I filed the bug here. debug-events: ... event17 POINTER_MOTION +70.55s -30.54/ 0.00 event17 POINTER_MOTION +70.56s -19.44/ 0.00 event17 POINTER_MOTION +70.58s -6.94/ 0.00 event17 GESTURE_SWIPE_BEGIN +71.06s 3 event17 GESTURE_SWIPE_UPDATE +71.06s 3 0.00/ 1.18 ( 0.00/ 3.58 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.08s 3 -0.21/ 0.80 (-1.41/ 5.37 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.10s 3 0.00/ 2.02 ( 0.00/10.74 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.12s 3 -1.29/11.70 (-3.75/34.00 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.14s 3 0.00/17.89 ( 0.00/48.32 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.16s 3 -1.39/15.90 (-3.75/42.95 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.18s 3 -2.08/11.26 (-5.62/30.42 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.20s 3 -1.39/ 5.96 (-3.75/16.11 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.22s 3 -1.39/ 1.99 (-3.75/ 5.37 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.26s 3 -0.63/ 0.00 (-1.87/ 0.00 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.28s 3 0.00/-22.13 ( 0.00/-66.21 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.30s 3 0.00/-14.58 ( 0.00/-39.37 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.32s 3 0.00/-6.63 ( 0.00/-17.90 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.34s 3 0.00/-2.65 ( 0.00/-7.16 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.36s 3 0.00/-1.33 ( 0.00/-3.58 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.38s 3 0.00/-1.33 ( 0.00/-3.58 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.40s 3 0.00/-0.66 ( 0.00/-1.79 unaccelerated) event17 GESTURE_SWIPE_UPDATE +71.42s 3 0.00/-0.66 ( 0.00/-1.79 unaccelerated) event17 GESTURE_SWIPE_END +71.62s 3 cancelled event17 POINTER_AXIS +71.83s vert -20.54* horiz 3.82* (finger) event17 POINTER_AXIS +71.85s vert -27.17* horiz 10.41* (finger) event17 POINTER_AXIS +71.87s vert -24.52* horiz 11.11* (finger) event17 POINTER_AXIS +71.89s vert -15.90* horiz 6.94* (finger) event17 POINTER_AXIS +71.91s vert -5.96* horiz 2.78* (finger) event17 POINTER_AXIS +71.93s vert -1.33* horiz 1.39* (finger) ... -event17 POINTER_BUTTON +75.24s BTN_LEFT (272) pressed, seat count: 1 event17 POINTER_BUTTON +75.34s BTN_LEFT (272) released, seat count: 0 event17 POINTER_MOTION +76.07s 0.00/ -1.81 event17 POINTER_MOTION +76.09s 0.00/-20.53 event17 POINTER_MOTION +76.11s 0.00/-26.51 The POINTER_AXIS motions result in the unwanted scrolling effect and stay until the POINTER_MOTION click happens. I'm on arch linux; libinput 1.9.4-1 libinput-git 1.10.0.r9.g582e3c00 linux 4.15.3-1 linux-ck-haswell 4.14.18-1 linux-ck-haswell 4.14.19-1 udevadm P: /devices/platform/i8042/serio1/input/input14/event17 N: input/event17 S: input/by-path/platform-i8042-serio-1-event-mouse E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse E: DEVNAME=/dev/input/event17 E: DEVPATH=/devices/platform/i8042/serio1/input/input14/event17 E: ID_BUS=i8042 E: ID_INPUT=1 E: ID_INPUT_HEIGHT_MM=77 E: ID_INPUT_TOUCHPAD=1 E: ID_INPUT_TOUCHPAD_INTEGRATION=internal E: ID_INPUT_WIDTH_MM=101 E: ID_PATH=platform-i8042-serio-1 E: ID_PATH_TAG=platform-i8042-serio-1 E: ID_SERIAL=noserial E: LIBINPUT_DEVICE_GROUP=11/2/7:isa0060/serio1 E: LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1 E: LIBINPUT_MODEL_TOUCHPAD_VISIBLE_MARKER=1 E: MAJOR=13 E: MINOR=81 E: SUBSYSTEM=input E: USEC_INITIALIZED=4970735