Re: [Qemu-devel] [RFC] qemu VGA endian swap low level drawing changes

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sun, 2014-07-06 at 12:13 +0100, Peter Maydell wrote:
> On 6 July 2014 12:08, Alexander Graf <agraf@suse.de> wrote
> > The guest's own acceleration can easily be non-linear, so we can't really
> > tell. However, FWIW we basically have 2 modes
> >
> >   1) absolute pointing device (usb tablet for example or vmmouse)
> >   2) relative pointing device
> >
> > In case 1, we can keep using the host cursor, and just tell the guest where
> > exactly the cursor is in absolute coordinates. This works very well with VNC
> > too ;).
> 
> Well, you *can* use the host cursor, but by default you should not
> (ie you still need to hide the host cursor and rely on the guest displaying
> its own pointer). 

Well, it depends what you mean by the guest draws its own pointer ... we
are in the specific case of cirrusfb HW cursor emulation which Gerd and
I are trying to fix.

Basically the guest doesn't draw anything. Gerd initial implementation
just passes the pixels to the dpy/qemu cursor, but while that probably
works fine in absolute mode, it's somewhat busted in relative mode at
least with SDL and gtk. 

The question is whether we can make it work that way (by basically
having grab and moving the host cursor) or do we really need to add a
layer for painting the cursor on top of the surface.

> You should also honour command line -show-cursor
> which overrides this to say "don't hide host cursor". Our SDL and Cocoa
> UIs get this right, GTK doesn't currently.

Cheers,
Ben.