Red Hat Bugzilla – Bug 201220
mouse cursor broken
Last modified: 2007-11-30 17:11:39 EST
Cursor in vncviewer window does not track with the desktop mouse cursor.
unfortunately I have not found any workaround.
Start a GUI installation of a full virt xen guest with xenguest-install.py.
connect to the installation with vncviewer
progress through the installation until the mouse becomes important.
Then, try to use the mouse or keyboard shortcuts.
This results in needing to chase the mouse around the screen. The mouse cursor
also seems to avoid some portions of the screen, and jumps to the nearest edge
of the vncviewer window. GUIs are completely unusable in vncviewer as result.
This affects installation of rawhide guests, and makes the default installation
of xen full virt guests fail.
also, at least the modal dialogs ignore keyboard input.
please, what arch are you using??
I've had some grief which sounds very similar to this and after a bit of
experimentation it doesn't seem to be VNC itself but the xen-vncfb interface
between VNC and the framebuffer for the virtual machine graphical console.
Basically the pointer accelleration doesn't match between the host VNC and the
client display, so the pointers get out of alignment and the VM pointer can seem
to jump around a bit. In my case the pointer accelleration on the VM was much
This is most problematic during the initial install of the VM and requires a lot
of effort realligning the pointers as one or the other runs to the edge of the
display, especially while going through all the installation component menus.
Once it's installed modifying the pointer motion settings can get the two
pointers to stick together fairly well, or VNC proper can be used.
I tested VNC server (proper, not the VNC-VM FB combination) on the VM post
installation and it works fine keeping the pointers together regardless of the
pointer accelleration settings.
Fedora Core 6, installed from the initial i386 32 bit release
CPU is an AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
I have an AM2 motherboard and need the "noapic" kernel option in case it's relevant.
A bit more playing with a new VM install. Regardless of the mouse accel on the
host machine the guest always moves the cursor faster in the guest with the
default setting and always at the same speed once the guest value is fixed up.
So it's always scaling whatever the accelleration on the host is by the guests
If mouse accel is turned down on the host the default guest still moves faster -
although it's much more managable as the guest pointer is moving at a more
I normally run in 1280x1024, so I changed host resolution down to 800x600 to
match the guest. Didn't change anything.
On my machine the working value for the guest mouse accelleration is
0.91200000047683714 whereas on a new VM I've run up the default is around 1.96
(In reply to comment #4)
so, you think that the problem is in different mouse acceleration??
I can use the mouse accelleration slider on the Xen guest OS (after finishing
the install) to get the pointers to move together (although they still have to
be aligned by cornering the guest OS mouse).
Istanbul screencast (~200K) http://members.westnet.com.au/penguinfancier/mouse.ogg
I'm guessing the problem is similar to the VMX Guest mouse issues (Xen User.pdf,
A.4.3) - that VNC is providing window relative mouse coordinates and the
xen-vncfb has trouble converting that into mouse motion for the guess OS virtual
Mouse acceleration is one part of the problem.
The other part of the problem is that your mouse pointer can leave the vnc
window and reenter in another point. Even without mouse acceleration, that
could still leave the pointers out of sync.
I think Markus is working on absolute mouse events for PVFB.
Perhaps a simple hack that might help would be some kind of hot key to turn
mouse tracking on and off, so you could turn it off, manually position
the real mouse over the virtual mouse, then turn it back on again. Don't
know if that would be any easier than a "real" fix.
This has been fixed as far as Xen is concerned: we transmit absolute pointer
coordinates. Unfortunately, X needs some manual configuration to make use of
that, and then it gets it wrong a bit, leading to jerky movement. See bug
243920 for details.