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

[Samuel Benson]

On Jan 26, 2009, at 5:05 AM, Stefano Stabellini wrote:

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.

Yeah, I had to do some math to get it to correctly accept the change in pixel depth,

but what I have seems to work 80% of the time which I find very odd.

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.

Yes it was, but a `make clean` fixed that right up.

The problem I'm seeing now is an x86 guest on an x86 host at 16 bit color,

Windows XP at 16bit color on an x86 mac seems to incorrectly read the pixel data; 24 bit works

like a charm. Gentoo in framebuffer mode at 16 bit color renders correctly on PPC host, as does

Windows XP in 16 and 24 bit color. There is no difference in the match calculation for 16bit

color in the host code for PPC or x86, so very odd that only the x86 version seems corrupt.

—Sam