On Di, 2014-06-17 at 12:42 +0100, Peter Maydell wrote: > On 17 June 2014 12:24, Gerd Hoffmann <kra...@redhat.com> 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