Am 25.01.2012 21:04, schrieb Gerhard Wiesinger:
Bugfix after reboot when vmmouse was enabled and another OS which uses
e.g. PS/2
mouse.
Details:
When a guest activated the vmmouse followed by a reboot the vmmouse was
still
enabled and the PS/2 mouse was therefore unsusable. When another guest
is then
booted without vmmouse support (e.g. PS/2 mouse) the mouse is not working.
Reason is that VMMouse has priority and disables all other mouse entities
and therefore must be disabled on reset.
Testscenario:
1.) Boot e.g. OS with VMMouse support (e.g. Windows with VMMouse tools)
2.) reboot
3.) Boot e.g. OS without VMMouse support (e.g. DOS) => PS/2 mouse
doesn't work
any more. Fixes that issue.
Testscenario 2 by Jan Kiszka <address@hidden>:
Confirm that this patch fixes a real issue. Setup: qemu.git,
opensuse 11.4 guest, SDL graphic, system_reset while guest is using the
vmmouse. Without the patch, the vmmouse become unusable after the
reboot. Also, the mouse stays in absolute mode even before X starts again.
Fixed by:
Disabling the vmmouse in its reset handler.
Signed-off-by: Gerhard Wiesinger <address@hidden>
I've been able to reproduce this the day before yesterday, on my version
of qemu-kvm 0.15.1 with this patch apparently fixing the mouse after a
kdump.
Yesterday however the reporter applied the patch himself to qemu.git and
reported this patch not to fix it on their side.
We boot into the desktop, then do:
# echo 1 > /proc/sys/kernel/sysrq
# echo c > /proc/sysrq-trigger
System then reboots after a while and at login mouse does or does not work.
I had originally tried to kdump with just a virtio drive w/ default
settings; then I tried with the reporter's setting of -smp 4 (and
cache=unsafe) and was able to reproduce it. Afterwards I was able to
reproduce without -smp 4 as well; no recompilation occurred. Guest was
the same SLES11 SP2 RC2 all the time.
So, is there any indeterminism involved? I.e. is the mouse unusability
maybe not 100% reproducible? Anything else that may need to be fixed
beyond this patch?
Patch does not break anything, so for now:
Tested-by: Andreas Färber <address@hidden>