| Summary: | Missing mouse button release event when multiple buttons are released | ||
|---|---|---|---|
| Product: | Wayland | Reporter: | Antti Korpi <an> |
| Component: | libinput | Assignee: | Wayland bug list <wayland-bugs> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | peter.hutterer |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | annotated example event log that reproduces the issue when fed through evemu-play | ||
While scanning the 1.8.3 to 1.9.1 diff [1], I noticed that the new debounce feature in this commit [2] has a DEBOUNCE_TIME constant of 12ms which corresponds closely to the duration between button releases (as reported by evemu-record) below which I see this problem, and above which I don't. I'll try to put together a testcase based on the evemu recordings. [1]: https://github.com/wayland-project/libinput/compare/1.8.3...1.9.1 [2]: https://github.com/wayland-project/libinput/commit/55d1bb1217388e99b9405654c14881a9ebf8f880 Looks like a duplicate of bug 103636? *** This bug has been marked as a duplicate of bug 103636 *** Just confirming that I agree this is a duplicate. Thanks! |
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 135377 [details] annotated example event log that reproduces the issue when fed through evemu-play Sometimes when I release any two mouse buttons in quick succession (about 0-15 ms apart), only one libinput button release event happens. The other button remains in a logical "down" state until I press and release it again. This makes some applications basically unusable. Logs show that evdev events are consistent with reality, but libinput events are sometimes not. When the issue happens, `sudo libinput debug-events --device /dev/input/event17` shows this: event17 POINTER_BUTTON +80.86s BTN_RIGHT (273) pressed, seat count: 1 event17 POINTER_BUTTON +80.87s BTN_LEFT (272) pressed, seat count: 1 event17 POINTER_BUTTON +81.35s BTN_RIGHT (273) released, seat count: 0 (No BTN_LEFT released appears even though the physical button is released.) A simultaneously running `evemu-record /dev/input/event17` showed these log entries in same span of time: E: 114.447480 0004 0004 589826 # EV_MSC / MSC_SCAN 589826 E: 114.447480 0001 0111 0001 # EV_KEY / BTN_RIGHT 1 E: 114.447480 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +678ms E: 114.466525 0004 0004 589825 # EV_MSC / MSC_SCAN 589825 E: 114.466525 0001 0110 0001 # EV_KEY / BTN_LEFT 1 E: 114.466525 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +19ms E: 114.934501 0004 0004 589825 # EV_MSC / MSC_SCAN 589825 E: 114.934501 0001 0110 0000 # EV_KEY / BTN_LEFT 0 E: 114.934501 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +468ms E: 114.943475 0004 0004 589826 # EV_MSC / MSC_SCAN 589826 E: 114.943475 0001 0111 0000 # EV_KEY / BTN_RIGHT 0 E: 114.943475 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +9ms (BTN_LEFT correctly shows as having been released.) I edited an evemu-record log of me manually reproducing the issue into a minimal annotated example (attached as `evemu-recorded.events`) and fed it through evemu-play, like this: sudo evemu-play /dev/input/event17 < evemu-recorded.events (/dev/input/event17 corresponds to the same mouse.) This reproduces the issue consistently, every time: it's easy to tell that the left mouse button is stuck by trying to interact with applications, until the additional button press at the end of the recording clicks once more to reset it. Frustratingly, I can't reproduce the same libinput log this way: libinput logs always look fine even though actual behaviour always breaks. Confusingly, libinput logs sometimes also look alright even when the issue has clearly happened. But sometimes they're clearly wrong, as shown above. Evdev logs are ALWAYS correct. # Hardware details I can only reproduce the problem with an ASUS Gladius mouse. (Its details are in the comments of the attached evemu-record log.) I couldn't repro on a different mouse model borrowed from a friend. # Software details $ xdpyinfo | grep 'X.Org version' X.Org version: 1.19.5 $ libinput --version 1.9.1 I upgraded from libinput version 1.8.3 to 1.9.1 the day before I first noticed this problem, so I suspect the culprit is in that diff. If you could use any further details, or have any ideas for how to deterministically repro this, just ask.