Bug 221360 - mouse pointer disfunctioning in vnc terminal for xen guest
mouse pointer disfunctioning in vnc terminal for xen guest
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Hugh Brock
Martin Jenner
:
Depends On: 211618 243920
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-03 21:07 EST by Jeroen Beerstra
Modified: 2008-02-26 18:50 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-26 18:50:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg config for paravirt guests only (786 bytes, text/plain)
2007-06-13 15:32 EDT, Daniel Berrange
no flags Details

  None (edit)
Description Jeroen Beerstra 2007-01-03 21:07:42 EST
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:
Comment 1 Daniel Berrange 2007-01-04 07:08:04 EST
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
Comment 2 Jeroen Beerstra 2007-01-05 14:47:48 EST
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. 
Comment 3 Stephen Tweedie 2007-01-05 16:10:04 EST
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.
Comment 4 Jeroen Beerstra 2007-01-06 19:38:02 EST
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.
Comment 5 Mike 2007-02-03 00:21:33 EST
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?
Comment 6 Daniel Berrange 2007-02-03 10:36:23 EST
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.
Comment 8 Greg Huber 2007-06-13 15:19:03 EDT
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.
Comment 9 Daniel Berrange 2007-06-13 15:31:16 EDT
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 
Comment 10 Daniel Berrange 2007-06-13 15:32:43 EDT
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.
Comment 11 Red Hat Bugzilla 2007-07-24 20:04:50 EDT
change QA contact
Comment 12 Chris Lalancette 2008-02-26 18:50:03 EST
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

Note You need to log in before you can comment on or make changes to this bug.