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

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

On Sun, 2014-07-06 at 14:09 +0100, Peter Maydell wrote:
> > 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.
> 
> I think this definitely needs to be done by the cirrusfb device model
> (or possibly by the common display code). Otherwise you're going to
> have to try to implement this in every single UI backend, and I bet
> you need a fallback implementation anyway because there's going to
> be at least one UI that can't implement it. And as Alex points out,
> trying to use the host mouse cursor doesn't work in pretty much any
> relative-mode mouse-grabbed setup.

It would be nice to implement that cursor support in the common code,
but I don't see how to do it without explicit support in any backend,
since the pixman surface goes straight to the backend.

If we do it in the cirrus model itself, then we basically have to
use the shadow pixmap always (can't ever share) and that means bringing
back a pile of conversion functions to the VGA model that we were
getting rid of (not hard ones but still, ie, 15, 16, 24 and 32bpp
non-swapped to 32bpp) which is somewhat sad.

The other option is to add "non-host" cursor support (painted-on) to
each backend, but that is starting to look like a lot more work than
what I signed up for :-)

So there is no "good" solution here. I'll look into bringing back the
shadow conversion functions and forcing cirrus to shadow the fb when
the cursor is active.

Another question: In the case where the host cursor actually works (such
as when emulating a tablet and the backend supports a cursor), how can
cirrus know so it can switch back to direct surface and stop painting a
second copy ? This is not clear to me...

Cheers,
Ben.