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

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

On Mon, 2014-06-30 at 13:14 +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > From what I can tell, we only ever call the cursor drawing callback on
> > non-shared surfaces. Should I deduce that the HW cursor emulation simply
> > doesn't work when using shared surfaces ? Or is there another path I
> > have missed to handle it ?
> 
> Hmm.  Looks like hw-cursor-on-shared-surface broken indeed.  Need to dig
> out a guest which actually uses it & go figure when testing your patch
> series ...

I don't think I broke it much more than it already was but then I
couldn't find a guest using it. I've tried the plain cirrus DDX in X and
it didn't have any problem... maybe windows ?

> > It makes sense in a way since we never want to draw the cursor in the
> > shared framebuffer, but we could probably handle it by having a small
> > separate pixman surface which we paint on top of the final render or
> > something like that (or link to a host side HW cursor if any) but I
> > can't quite see anything in the code.
> 
> There is infrastructure to inform the ui code how the cursor should look
> like (grep for "dpy_cursor_define"), so we actually can use the hosts
> hardware cursor support.  cirrus doesn't use it though.

Right. A quick fix would be to add a flag to force always using a shadow
surface and set it in cirrus ... I'm not sure anybody will notice the
performance difference.

My main problem is whatever more complicated than that would require
testing and I yet have to find something to run in the guest that uses
that cirrus HW cursor.

Cheers,
Ben.

> cheers,
>   Gerd
>