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.