From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRlbG-0008SB-SH for qemu-devel@nongnu.org; Tue, 27 Jan 2009 05:55:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRlbF-0008RQ-Jk for qemu-devel@nongnu.org; Tue, 27 Jan 2009 05:55:22 -0500 Received: from [199.232.76.173] (port=46029 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRlbF-0008RL-Gp for qemu-devel@nongnu.org; Tue, 27 Jan 2009 05:55:21 -0500 Received: from smtp.eu.citrix.com ([62.200.22.115]:50838) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRlbF-0006of-3Q for qemu-devel@nongnu.org; Tue, 27 Jan 2009 05:55:21 -0500 Message-ID: <497EE659.6060207@eu.citrix.com> Date: Tue, 27 Jan 2009 10:47:53 +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> In-Reply-To: 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: > 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. > 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: red 5 bits green 6 bits blue 5 bits 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);