Red Hat Bugzilla – Bug 242676
Mouse pointer in VM moves at incorrect speed
Last modified: 2008-05-15 08:24:24 EDT
Description of problem:
The mouse pointer within the VM does not move at the same speed as my desktop
It seems like the host mouse DPI and the guest mouse DPI are set differently. If
the host moves more slowly, there aren't any major problems - if it moves more
quickly, even when the pointer is captured you but against the extents of the
console window - parts of the guest screen therefore become inaccessible.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup new virtual machine in virt-manager, e.g., install RHEL4
2. Reach first graphical screen (Welcome to RHEL_ServerCD)...
On first graphical screen in install, note that mouse pointer moves more quickly
than desktop pointer.
The pointers ought to move together, in the same position and with the same speed.
This is as plain an install as possible; I haven't configured much. The VM is
setup as a QEMU machine with full virtualisation but on the same architecture as
I am seeing the same problem as well, the guest OS is Win XP in QEMU.
I see the same problem with QEMU. If I manually run qemu without -vnc the mouse
works fine in the SDL display.
Here is a description of the problem and how to solve it (though I have no idea
where to put the config flag in fedora):
Where do I put the (usbdevice tablet) string to get the usbdevice mentioned in
the xen user manual?
If I put it in /var/lib/xend/domains/88fe...53/config.sxp it will get removed
the next time I run the domain.
I don't see any hvm section anywhere else on the system.
Based on the email
and the webpage
I think it is near impossible to get usbdevice tablet working in Fedora. I did
try changing <graphics type='vnc' port='-1'/> to <graphics type='sdl'/>
foo is the domain:
virsh dumpxml foo > /tmp/foo.xml
edit /tmp/foo.xml and change line <graphics type='vnc' port='-1'/> to <graphics
virsh define /tmp/foo.xml
but xen still seems to uses vnc. (Despite the creation of (device (vfb (type
sdl) (uuid 54..86))) in the config.sxp file.
So probably the easiest solution to this is probably to add the gui required for
sdl versus vnc in virt-manager and make graphics type='sdl' work.
I don't think it will be quick to get vnc to properly do the mouse handling.
Virt manager cannot & will not support SDL graphics. SDL merely pops up a
standalone window on the X server - if you kill that window the VM dies. Clearly
this is useless because you can't keep the window open all the time. SDL is also
useless for remote management of VMs.
The solution is to make the mouse work correctly under VNC which is being
attacked on a number of angles. For fullyvirt VMs we will be enabling a graphics
table suitable for the guest OS, while paravirt VMs will 'just work' with a few
tweaks to X org config.
So, until this patch is added, is there any way to enable the appropriate
graphics table in the meantime?
There's no easy option until we add support for it in libvirt I'm afraid. We
have a design for making it work - its just a question fo developer time.....
change QA contact
I see a very similar issue using virt-manager with qemu-kvm guests - the
mouseperiodically can't move past a particular horizontal or vertical line - it
feels like the mouse pointer is bumping up against the edge of the window, but
it clearly isn't. This doesn't occur with qemu-kvm running in its own Xwindow,
only within virt-manager. This makes the guest unusable. This is on F7
Bumping priority of this, as I think this is a massive usability issue.
Happy to report that I don't see this anymore in F-8 with
I see that VMs are now created with a tablet device. The downside of this is
that even with the VM doing nothing, top shows virt-manager using 30 % CPU. Not
sure if this is related or not to having atablet virtual device.
Do you really mean virt-manager is using 30% CPU, or do you mean that the
virtual machine is using 30% CPU ?
And, yes, it is the USB tablet device that enables the cursor to move accurately.
Yes, sorry, what I said was misleading.
The process that consumes 30 percent CPU is the qemu instance.
*** Bug 437027 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
As Jonathan pointed out in comment 11, this seems to work fine in F8.