<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Missing mouse button release event when multiple buttons are released"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103673">103673</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Missing mouse button release event when multiple buttons are released
</td>
</tr>
<tr>
<th>Product</th>
<td>Wayland
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>libinput
</td>
</tr>
<tr>
<th>Assignee</th>
<td>wayland-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>an@cyan.io
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=135377" name="attach_135377" title="annotated example event log that reproduces the issue when fed through evemu-play">attachment 135377</a> <a href="attachment.cgi?id=135377&action=edit" title="annotated example event log that reproduces the issue when fed through evemu-play">[details]</a></span>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>