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 X-server... kernel-xen-2.6.20-2925.9.fc7 xen-3.1.0-0.rc7.1.fc7 xen-libs-3.1.0-0.rc7.1.fc7 xorg-x11-server-Xorg-1.3.0.0-7.fc7 How reproducible: 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 Actual results: Expected results: Additional info: 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. Pete Please don't hesitate
Just to check, it's the *host* (dom0) desktop that gets stuck, not the guest console?
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.
Hi, 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. Pete
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 pointer jump.
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!
Meh! 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... :( Pete
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: http://docs.fedoraproject.org/release-notes/ 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.