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):
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)
Remote mouse pointer inside the vnc window is displayed at a different location
then the system mouse pointer and moves at a different speed.
Remote mouse pointer and system mouse pointer should overlap, or to put it
different there should only be one mouse pointer.
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.