I believe I am onto the cause of this issue, because the input events are coming from a multi threaded source (in my instance spice) keyboard and mouse input share common code paths without any thread interlocking.
Since keyboard input takes priority over mouse, when more mouse events are being handled it is overwriting and swapping out the data the guest was expecting with mouse input data. In short, there is a race condition here. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1722884 Title: keyboard input while mouse moving triggers mouse failure Status in QEMU: New Bug description: When QEMU is getting a ton of mouse input events if keys are pressed on the keyboard the scan code will be corrupted causing erroneous behavior. I have confirmed this problem in the latest version in git (530049bc1dcc24c1178a29d99ca08b6dd08413e0). After the erroneous behavior the operating system issues a keyboard reset which prevents the mouse from functioning until the operating system is restarted. This seems to only occur if the PS2 mouse is being used as the input, the tablet input device doesn't exhibit this behavior. The same problem was reported here also: https://openxt.atlassian.net/browse/OXT-562 Host : Debian 9 CPU : Ryzen 1700X RAM : 16GB Kernel: 4.12.0-0.bpo.2-amd64 Guest : Windows 10 (KVM) RAM : 8GB (1GB Huge pages) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1722884/+subscriptions
