Windows guest mouse and keyboard input glitch
Description
Environment
NUC BLKNUC5I5MYHE
Validation Steps
Activity
Daniel Smith October 12, 2016 at 6:10 PM
This has now been reproduced on the following devices,
Toshiba Tecra R940 (PT43GU)
Toshiba Portege R930 (PT331U)
HP EliteBook folio 9470m
HP EliteBook 850
Ross Philipson June 21, 2016 at 5:32 PM
Eric's latest comment after putting this in review:
" R6.0-No. NUC only, unlikely to be fixed in time, only affect HVM
Windows guests without PV tools on NUC systems (probably not all NUCs on
top of that). Should lower priority."
Dropping it out of review.
Eric Chanudet June 2, 2016 at 12:11 PM
This glitch only reproduces on NUC (BLKNUC5I5MYHE), very surprisingly...
Confirmed using build #91 with the NUC and an XE2. JEd tested another machine as well.
Eric Chanudet May 30, 2016 at 3:09 PM
No repro using QEMU 1.4.0 and usptream (2.6.0?) full emulation (no Xen).
QEMU 2.0.2, with Xen 4.5, has a very similar behaviour: moving mouse + typing on the keyboard will stutter and have the mouse behave erratically.
Eric Chanudet May 20, 2016 at 4:04 PM
On Windows 10, there is apparently another glitch. The guest will spend a couple of seconds reading the status register repeatedly.
This can be worked-around by setting D-WORD32 "PollStatusIterations" to "1" in the registry:
Nevertheless, the same behaviour will occur.
Starting a Windows 7 or 10 guest without tools installed trigger some weird input behaviours. Moving the mouse while typing a key will result in the guest seeing a different key pressed (depending on the mouse movement).
Example:
Moving the mouse horizontally to the right while repeatedly pressing "a" will eventually register as "7"
Moving the mouse horizontally to the left while repeatedly pressing "a" will eventually register as "o"
Moving the mouse vertically down while repeatedly pressing "a" will eventually register as "'"
Moving the mouse diagonally down and left repeatedly pressing "a" will eventually register as Alt (right-alt most likely)
This seems to match first byte of mouse packet: bit3 always on, bit4-5 x,y sign (KEY_7 == 0x8, KEY_O == 0x18, KEY_APOSTROPHE == 0x28, KEY_RIGHTALT == 0x38).
Logging input-events in QEMU does not reveal anormal exchanges.
Logging ps2 IO accesses reveal that the guest resets the PS2 mouse device when the problem manifests itself:
(The entire reset dance seems correct as well: http://www.computer-engineering.org/ps2mouse/)
But, log show the guest receives correct values for keyboard input (no trace of the invalid '7', 'o' and what not that the guest sees).