Bug 206313

Description of problem:
With VNC there are usually two cursors, the (physical) local client side cursor
, and the remote cursor (which tracks the local cursor). The VNC protocol also
allow for the remote cursor to be rendered locally to reduce effects of latency. 

The Xen Paravirt framebuffer is even more complicated than this though, adding a
third cursor - the one rendered by the guest OS into the virtual framebuffer. If
the VNC client supports the RichCursor RFB extension the user will still only
see two of the cursors -the guest rendererd one & the local cursor - the server
side one is not shown with RichCursor extension.

The problem is that not all clients support RichCursor, and in those cases
you'll actually see 3 cursors for a single display. The server-rendererd one in
this case is actually locked, stuck at 0,0 so you only see the bottom-right
quarter of it.

The issue is really that the intermediate VNC server cursor is totally pointless
since all you care about is the guest cursor & the real local one. This
intermedia cursor should simply be disabled altogether - which also fixes the
problem of it being rendered stuck at 0,0 in non-RichCursor clients.

Version-Release number of selected component (if applicable):
xen-3.0.2-33, virt-manager-0.2.1-3

How reproducible:
Always

Steps to Reproduce:
1. Run a paravirt guest with VNC server
2. Connect to guest console with virt-manager
3.
  
Actual results:
Notice bottom-right quarter of server-generated cross-hair cursor

Expected results:
Server generated cursor is hidden - only guest & local cursors visible.

Additional info: