Cursor in vncviewer window does not track with the desktop mouse cursor. vnc-4.1.1-39.fc5 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 higher. 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 value. 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 "normal" rate. 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 device.
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.