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

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

On Sat, 2014-06-21 at 15:37 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-19 at 11:36 +0200, Gerd Hoffmann wrote:
> > If not -- then I prefer to play save and not use a vbe register to avoid
> > ending up with two incompatible bochs interface revisions.  If you don't
> > like the pci config space option -- the mmio bar has plenty of free
> > space left ;)
> 
> I'll find something :-)
> 
> Another advantage I realize in going down that path is that's yet another
> use of target endian removed from hw/ which gets us a little step closer
> to having to make the whole hw/ stuff target neutral.

Ok, I hit a (small) problem ...

So I've cut out a ton of cruft form vga (and a bit from cirrus). However
there is one bit that worries me: cirrus cursor emulation.

>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 ?

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.

I'm asking because I'm increasing the cases where we share the surface,
from 16 non-swapped and 32 to 15 and 16 non-swapped, 24 and 32bpp, which
means that practically speaking the HW cursor painting code in cirrus
will never be called unless we are in 8bpp, reverse endian, or force
surface unsharing somewhat.

Or did I miss something ?

Cheers,
Ben.