QEMU mouse button gets stuck if spice-vdagent starts when the button is down
If spice-vdagent starts its uinput device when the QEMU USB Tablet button is down, the release event is never sent and we end up with a permanently stuck mouse button.
- fresh Fedora 32 VM, select Gnome on Xorg (because we thought it was an xserver bug first)
- select username, type your password
- hit enter and after ~200ms or so hold the left mouse button down until the session is there
- notice the button is stuck down
The slight delay is required so the button happens between gdm's spice-vdagent shutting down and before the user one starting up. Alternatively you can click like crazy in which case you have a roughly 50% chance of hitting it.
You can verify the bug by running
libinput record or
evtest against the QEMU USB tablet device. Start it while gdm is active and the clicks will start coming in once the gdm vdagent shuts down. When the bug triggers, the last event is a button down event:
- evdev: - [ 9, 326927, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated) - [ 9, 326927, 1, 272, 1] # EV_KEY / BTN_LEFT 1 - [ 9, 326927, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +9238ms
I don't know whether it's a vdagent bug or whether there's something in qemu that reroutes the events once the vdagent initializes the device. There's no EVIOCGRAB on the QEMU USB tablet device, so I don't know why the event on the QEMU tablet gets lost. But all signs right now point at vdagent.