From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LS856-0006hF-4v for qemu-devel@nongnu.org; Wed, 28 Jan 2009 05:55:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LS855-0006fz-BN for qemu-devel@nongnu.org; Wed, 28 Jan 2009 05:55:39 -0500 Received: from [199.232.76.173] (port=34121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LS855-0006fl-1J for qemu-devel@nongnu.org; Wed, 28 Jan 2009 05:55:39 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:11238) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LS854-0006mM-0G for qemu-devel@nongnu.org; Wed, 28 Jan 2009 05:55:38 -0500 Message-ID: <498037C7.8010807@eu.citrix.com> Date: Wed, 28 Jan 2009 10:47:35 +0000 From: Stefano Stabellini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] [v2] Update cocoa.m to match new DisplayState code References: <3097312F-7315-42BA-AF5D-4C026CD874FD@digitalescape.info> <497D9914.70004@eu.citrix.com> <497EE659.6060207@eu.citrix.com> <55D6B519-C248-4AE1-B0E5-A9AB4FF45851@digitalescape.info> In-Reply-To: <55D6B519-C248-4AE1-B0E5-A9AB4FF45851@digitalescape.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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.