Bug 221360

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