Description of problem: When I open a connection to the vncserver xen starts for guests domains, the mousepointer for the vnc session is not in sync with the system mouse pointer, so I see two mouse pointers, one is the system mouse pointer and the other the remote one. Also the remote mouse pointer moves faster then the system mouse pointer, this makes things a bit better as it allows me to reach a bigger part of the remote desktop before the system mouse pointer moves outside the vnc window and the remote mouse pointer stops working. The fact that both pointers look the same (host and guest are both FC6) makes it even worse. I tried vncviewer, krdc and tsclient apart from virt-manager's builtin vnc viewer, all have the same problem so I suspect a problem with the vnc backend and therefore I file this bugreport against xen. BTW same problem with a SDL console, allthough the system mouse pointer seems to stick a little bit to the SDL window so the remote mouse pointer keeps working when the system mouse pointer would otherwise leave the window and loose focus (don't know how to better describe this). BTW2 don't have this problem when I start the vncserver that comes with FC6. Version-Release number of selected component (if applicable): kdenetwork-3.5.5-0.1.fc6 kernel-xen-2.6.18-1.2869.fc6 tsclient-0.148-5.fc6 virt-manager-0.2.6-3.fc6 vnc-4.1.2-8.fc6 xen-3.0.3-1.fc6 How reproducible: Steps to Reproduce: 1. Install Xen and Dom0 FC6 kernel and related tools and boot this 2. Use virt-manager (or virt-install) to setup a FC6 guest 3. Start FC6 guest and open the vnc console from within virt-manager (or manually connect with your favorite vnc viewer app) Actual results: Remote mouse pointer inside the vnc window is displayed at a different location then the system mouse pointer and moves at a different speed. Expected results: Remote mouse pointer and system mouse pointer should overlap, or to put it different there should only be one mouse pointer. Additional info:
This is a known problem with the guest operating systems not understanding absolute mouse co-ordinates. They thus fall back to using the relative co-ords and apply the mouse acceleration again, making the mouse very erratic. This same issue is also tracked against RHEL-5 in bug 211618
But why am I not seeing this with the Xen Demo cd? The vncviewer window that appears when you start the CentOS guest for example works just fine.
If you use a dedicated vnc server in the guest, then you won't have any problems --- the guest will be talking VNC protocol natively from the X server, and will get everything right. But that approach is limited in many ways --- it doesn't give you access to the guest's text console, or RHGB boot, or multiple virtual terminals for example; and it requires running a non-default X server (VNC cannot simply be loaded as an X driver module, it requires a whole different server to be started.) So it really doesn't integrate well with a single distribution designed to be run either natively or under Xen. With FC-6, we took the approach of a "paravirt framebuffer", in which the guest does not speak VNC directly, but rather has a virtual framebuffer, which can be driven by the normal kernel and X framebuffer drivers. So boot logos, boot text messages, virtual terminals, graphical boot screens and X/gdm all Just Work in the guest. It's a far better long-term solution, and has recently been merged into the upstream Xen code base, but it has one big problem: it relies on the default X server (which is good), but the default X server in Linux does not auto-detect absolute pointer devices (which is not so good --- it leaves us with X getting relative mouse events, which results in the decoupled mouse behaviour here.) That's something to be fixed now that the core paravirt framebuffer is working, but it didn't make it into FC-6.
Sorry should have looked better. The XenSource demo cd uses a vnc server on the guest, I just assumed it used xenfb. Glad to hear you are working on this.
I'm glad to see that I'm not the only one with this problem, and that it's a known issue that will eventually be addressed. Is there a rough estimate for when this issue problem might be resolved. The latest stable updates for FC6 still exhibit the problem. Is there a fix in any of the testing repositories, or in the new FC7 Test 1 release?
The problem is under very active investigation. We're pretty confident that by the time Fedora 7 reaches its GA release, we'll have the mouse pointer working perfectly for paravirt guests. We'll also have much improved way of dealing with the relative mouse pointer for fullvirt guests. Depending on how complex the fix is, we may consider doing an update for FC6. Will post more info to this ticket when we have a solution.
Well, I guess this didn't make it into F7. I'm running a FC6 guest on a F7 host and am having terrible trouble with the mouse. It seems that there is a ramdom offset from the actual cursor position and the position within the VNC window. This has the effect of making portions of the guest window inaccessible and possible totally screwing up the cursor in the host window (jamming it against one edge for example). The host window problem seems to be related to when and where the cursor is when you exit the guest window. Also, I only see problems if I open the guest window. If I login and never open the guest, even though it's running, I never see any mouse corruption.
It is now possible to configure the X server inside the guest to get a mouse which tracks motion 1-to-1. Unfortunately at this time a bug in the X evdev driver means we can't enable this by default yet
Created attachment 156906 [details] Xorg config for paravirt guests only This shows suitable config for Xen paravirt guests only. This is not applicable to HVM guests which requires a different solution.
change QA contact
This report targets FC6, which is now end-of-life. Please re-test against Fedora 7 or later, and if the issue persists, open a new bug. Thanks