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:
Created attachment 136179 [details] Patch to disble VNC cursor
Pushed to rawhide in xen-3.0.2-39