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

[Gerd Hoffmann]

On Di, 2014-06-17 at 12:42 +0100, Peter Maydell wrote:
> On 17 June 2014 12:24, Gerd Hoffmann <address@hidden> wrote:
> > pl110 looks easy enough, so maybe I should just go convert it (and
> > sprinkle in comments) so there actually is a good example to follow.
> > Which arm board has one?  Suggestions on how to test it?
> 
> It's present in a number of them; the simplest one to test is
> probably versatilepb, because you can get some prebuilt images
> from Aurelien's website:
> http://people.debian.org/~aurel32/qemu/armel/

Thanks.  The linux framebuffer driver uses only the little endian modes
though.  And it looks like it doesn't support 32bpp.

Is there some way to test the bigendian modes too?

Also:  How does 16bpp on bigendian looks like?  According to both specs
and emulation code the pl110 always swaps 4 bytes (32bit words).  As far
I know 16bpp on bigendian usually is an array of 16bit words (each in
bigendian order) though.  Which implies even with pl110 in bigendian
mode on a bigendian host I can't feed the data into pixman as-is because
I'll end up with swapped pixels then.  Correct?

I'm thinking about splitting the conversion (for truecolor modes, still
need to think about how to do paletted modes best) into two steps:
First byteswap to bring the data into a format pixman can handle, then
feed into pixman for further conversion.  Which probably comes with a
performance penalty (but maybe not due to pixman performing better than
our self-made conversion code).  It will only hit the more unusual guest
framebuffer formats which I can't feed into pixman directly.  Acceptable
or not?

cheers,
  Gerd