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

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

Samuel Benson wrote:

> 
> On Jan 27, 2009, at 4:47 AM, Stefano Stabellini wrote:
> 
>> As I was telling you before, the guest in 16bpp is one of the "odd"
>> cases, because everything usually is converted into 32bpp.
>> It only happen when both host and guest are x86 because the 16bpp
>> optimization that the displaystate interface change introduced is only
>> enabled when guest and host have the same endianness.
> 
>> I think the way you specify bitsPerComponent may be incorrect in the
>> 16bpp case, because the format is actually 565:
>>
> 
> It was; since OS X is an RGBA system, it also assumes everything to be
> RGBA, so when I did the
> math for 16bpp, it comes out 4444. It turns out OSX not only assumes,
> but forces everything
> it does into RGBA; valid bits-per-component are forced into powers of 2.
> Also, according to
> CoreImage mail-list, OSX does not support RGB 565;  however it does
> support XRGB 1555.
> 
>> isn't there a way to provide the full color masks like with sdl?
>>
>> guest_screen = SDL_CreateRGBSurfaceFrom(ds_get_data(ds),
>> ds_get_width(ds), ds_get_height(ds),
>>                                            ds_get_bits_per_pixel(ds),
>> ds_get_linesize(ds),
>>                                            ds->surface->pf.rmask,
>> ds->surface->pf.gmask,
>>                                            ds->surface->pf.bmask,
>> ds->surface->pf.amask);
> 
> I spent a couple hours pouring thru the documentation, and being unable
> to find a similar
> function, I was forced to google. That's when I came across the above
> mentioned "answer".
> 
> Now, you stated that the 16bpp case only exists when both host and guest
> are x86; Is there a way
> I can trick it into thinking its a x86 guest on a ppc host so it would
> return the upconverted
> 32bpp? I'm assuming it would be just a toggle of the
> QEMU_BIG_ENDIAN_FLAG on the DisplaySurface.
> 
> The only other option I can think of is passing it thru some CoreVector
> Imaging constructs to
> try to convert it to XRGB and telling it to ignore the leading fake
> alpha bit.
> 




Maybe cocoa does not support RGB565 rendering but it has to provide a
way to convert preexiting RGB565 pictures into a format that it can
actually render.  Isn't there an image manipulation library, or
something like that?

Sorry for insisting on this but I would like to expoit all the other
possible options before adding hacks to the interface or removing the
16bpp shared video buffer.

Anyway if it is really not possible I could add something like:

---

diff --git a/hw/vga.c b/hw/vga.c
index 2084ff4..b742c78 100644
--- a/hw/vga.c
+++ b/hw/vga.c
@@ -1621,7 +1621,7 @@ static void vga_draw_graphic(VGAState *s, int full_update)
         disp_width != s->last_width ||
         height != s->last_height ||
         s->last_depth != depth) {
-#if defined(WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN)
+#if defined(WORDS_BIGENDIAN) == defined(TARGET_WORDS_BIGENDIAN) && !defined(CONFIG_COCOA)
         if (depth == 16 || depth == 32) {
 #else
         if (depth == 32) {

---

this would prevent 16bpp to ever be expoed to cocoa, but you would still be
required of being able to render inverted ARGB8888, I mean the pixel
format specified by console.c:qemu_different_endianness_pixelformat in
32bpp case.
Do you think cocoa can do that?
You can try if that works using a Windows VM with stdvga in 32bpp (no 24bpp,
I really mean 32bpp) on a PPC host.