[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] [v2] Update cocoa.m to match new DisplayState c
From: |
Stefano Stabellini |
Subject: |
Re: [Qemu-devel] [PATCH] [v2] Update cocoa.m to match new DisplayState code |
Date: |
Wed, 28 Jan 2009 10:47:35 +0000 |
User-agent: |
Thunderbird 2.0.0.14 (X11/20080505) |
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.
Re: [Qemu-devel] [PATCH] [v2] Update cocoa.m to match new DisplayState code, Stefano Stabellini, 2009/01/26
Re: [Qemu-devel] [PATCH] [v2] Update cocoa.m to match new DisplayState code, Stefano Stabellini, 2009/01/26