Red Hat Bugzilla – Bug 243649
Problems with mouse pointer when running HVM guest
Last modified: 2008-06-16 21:32:36 EDT
Description of problem:
When I start a guest machine from the command line (xm create winxp00.hvm),
after an unspecified amount of time, the mouse pointer in my Gnome session
becomes "stuck" to the left hand side of the screen. I am able to move the mouse
freely along it's vertical axis, but moving it away from the left hand side of
the screen results in it just "snapping back" to the limit of the screen.
If I move the mouse slowly enough, I can sometimes get it away from the screen
edge long enough to click a button, but if I move the device a bit too quickly,
it's back to the edge again! Note: I do not actually have to be connected to the
console of the VM (either by SDL or VNC) for this issue to occur.
Version-Release number of selected component (if applicable):
Not sure off the component to blame, but this only happens when HVM guests are
instantiated, so I assume it's Xen, I suppose it could be an issue with the
This will occur without fail every time I start an HVM guest.
Steps to Reproduce:
1. Log into Gnome Session
2. Configure guest using skeleton config files in /etc/xen
3. Start guest from gnome terminal as root using: xm create [guest_vm]
4. Continue to use desktop
I am running the stable i386 version of Fedora 7, with all the packages updated.
The machine is an IBM/Lenovo ThinkPad X60s. I can't see anything in
/var/log/messages or dmesg that might indicate what the problem is, however, if
you'd like me to send you some log info, or any other info, please don't
hesitate to get in touch.
Please don't hesitate
Just to check, it's the *host* (dom0) desktop that gets stuck, not the guest
Well, the issue occurs on the host (dom0), but the effect propagates to the
guest machine when using the Virtual Machine Console window provided in Fedora 7.
If the problem occurs while the cursor has been "grabbed" by the VM Console
window (or I manage to get the cursor away from the screen edge long enough to
select the VM Console), the cursor is simply unable to move left, and any motion
to the right reduces the range of motion on the VM Console considerably!
TBH, this looks like a *host* issue to me...
Oh, and I can work around the issue by logging out of my gnome session (not
rebooting), when the login screen appears again, the mouse pointer is OK. I can
then log back in, and begin to use my desktop and the guest machine normally,
until the problem occurs again.
Just a quick update - I'm currently running 2 para-virtualised guest instances,
and I have not experienced the mouse pointer issue.
Maybe the issue lies in the qemu emulation code? Just a thought.
Created attachment 158279 [details]
xev output during erratic mouse behavior
This is a log of the output of xev while the mouse is demonstrating erratic
behavior. Each LeaveNotify event corresponds (roughly) to an instance a
I can confirm this bug. I've seen it on a Dell Optiplex 745 with ATI video.
I've also seen it on a Dell Latitude D620 with nVidia video. No proprietary
drivers are installed on either system.
It's interesting to note that the touchpad doesn't seem to be affected on the
D620 (the pointer stick and USB mouse are), although as noted in Comment #1 it
appears that acceleration to the right is what exposes the problem. It's
possible that the touchpad sensitivity is configured low enough that the pointer
never accelerates enough to trigger the bug.
I'm not sure how to proceed in troubleshooting this issue. If it's of interest,
I've attached the output of xev during an erratic mouse session. Each
LeaveNotify event rougly corresponds to a pointer jump. I'm happy to provide
additional info if needed.
One thing to try - in the Windows guest - find the OS settings for mouse and set
the 'acceleration' to zero - or whatever the lowest/slowest/minimum value it
allows is. Basically QEMU emulates a PS/2 mouse, which works in relative
co-ordinate mode. So its basically sending 'deltas' for each motion event - most
OS will apply 'acceleration' - if you move between 1 & 5 pixels, it'll typically
translate on a 1-1 basis, but if you move say 10 pixels the OS may accelerate
it to a 20 pixel movement. The trouble is, the host OS is also doing the same
thing with your real mouse. So a movement of 10 pixels of you physical mouse
will correspond to 20 pixels on the host display, which gets accelerated again
in the guest, causing say 40 pixels of movement in the guest. This is why you
can end up with crazy movement inside the guest. Setting the mouse acceleration
to as low a value as possible often helps mitigate the problem to some degree,
though its not a perfect fix by any means.
As noted in the original report and in Comment #2 the problem occurs in the host
OS (dom0), not the guest. Once the problem is triggered the first time it will
occur consistently regardless of whether the mouse is interacting with the guest
os window. I am aware of the 'delta' based mouse sync issues you're talking
about, but my impression what that they caused problems in the guest OS and that
the host continues to behave sanely, which is not the case with this bug.
I'm not near my xen box right now, but will do some checking on Monday regarding
the guest mouse settings to see if they have any effect.
I have tried Daniel's suggestion to reduce the acceleration for the mouse
pointer to zero and I have not experienced the issue all day!
My steps were:
- Open Control Panel.
- Double click the "Mouse" icon.
- Click the "Pointer Options" tab.
- In the "Motion" section, drag the slide bar all the way to the left (lowest
setting) and removed the tick from the "Enhance pointer precision" box.
- Click "OK".
Like I say, I have been using the same Windows VM instance all day, and my mouse
pointer has been behaving itself. I'm off home now, but when I'm back at work
tomorrow, I'll continue testing this.
Thanks for the suggestion Daniel!
Started my Windows guest instance today, and the problem occurred almost
instantly! Guess the acceleration option doesn't stop it after all, and I was
really lucky yesterday... :(
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
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.