Re: [Qemu-devel] [PATCH] [v2] Update cocoa.m to match new DisplayState code

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

Samuel Benson wrote:

> Version 2 does as follows:
> 
> [1]: Corrects endianness on issues by using native BGR to RGB conversion
> [2]: Uses DisplayState accessors for obtaining graphics context
> information, which
> [3]: Removes now unused variables, and
> [4]: Allows reading of varying color modes (32bit/24/16), and converting
> to native colorspace
> [5]: Attempts to keep itself centered on screen (as opposed to bottom
> right, which immediately
>      goes off screen after bios load) on context changes (window resizes)
> 
> Testing working on i386 (gentoo, Windows 2000) and PPC (debian) guests
> on PPC and x86 Macs.
> 
> In regards to [4], Windows 2000 displays fine on quick tests, but on the
> lowest setting
> I could test, 16bit color depth at 4bpp, colors are slightly off. I used
> gentoo
> install-x86-minimal-2008.0 in framebuffer mode to test above setting;
> the usual grey text is
> now blue, and Tux appears to be BGR shifted. I do not know if previous
> code worked at such
> a low color setting.
> 
> Signed-off-by: Samuel Benson <qemu_ml@digitalescape.info>





This patch looks fine to me: it uses the new interface the way it is
supposed to be used.

However if you are seeing some color problems you may still have few
bugs in the cocoa color conversion code.
To help you track them down, I'll explain a little bit more the pixel
formats that the graphic card exposes to cocoa, no matter what the host
endianness is:

- 24 bits depth, 32 bits per pixel (8888)
- 16 bits depth, 16 bits per pixel (565)

usually the pixel format is RGB, look at
console.c:qemu_default_pixelformat to have the details.
There is just one exception: if the guest endianness differs from the
host endianness and the guest native color depth is 24 bits with 32 bits
per pixels, then these masks are used instead:
console.c:qemu_different_endianness_pixelformat.
You'll probably never see this latter case in your tests, so you can
just ignore it for the moment.

Did you do the blue shifted Tux test on a ppc Mac? If so my guess is
that you have to call kCGImageAlphaNoneSkipLast instead of
kCGImageAlphaNoneSkipFirst because the format exposed by the graphic
card is already converted into big endian.