From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L3auu-0000Vm-GO
	for qemu-devel@nongnu.org; Fri, 21 Nov 2008 13:39:44 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L3auu-0000VZ-3d
	for qemu-devel@nongnu.org; Fri, 21 Nov 2008 13:39:44 -0500
Received: from [199.232.76.173] (port=34708 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L3aut-0000VW-UO
	for qemu-devel@nongnu.org; Fri, 21 Nov 2008 13:39:43 -0500
Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:41917
	helo=SMTP.EU.CITRIX.COM)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1L3aut-0006d6-I6
	for qemu-devel@nongnu.org; Fri, 21 Nov 2008 13:39:43 -0500
Message-ID: <49270151.7030206@eu.citrix.com>
Date: Fri, 21 Nov 2008 18:43:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 3 of 5] [UPDATE] remove bgr
References: <4926EADE.9020303@eu.citrix.com> <4926FCB2.3030002@codemonkey.ws>
In-Reply-To: <4926FCB2.3030002@codemonkey.ws>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Anthony Liguori wrote:

> Stefano Stabellini wrote:
>> Do not handle bgr host displays in the backends.
>>   
> 
> -ETOOLITTLEDESCRIPTION
> 
> Seriously though, where does bgr get handled now?  Have you tested on a
> bgr display?
> 
> The bgr code is notoriously easy to break right now so changes need
> testing.
> 

Sorry you are right :)
I have written a little bit more about this in the first patch.

Right now a bgr flag exists so that sdl can set it, if the SDL_Surface
is bgr.
Afterwards vga.c does the needed conversion.

With my patches is sdl that is responsible for rendering the format
provided by vga.
Vga provides a DisplaySurface (ds->surface) in 16 or 32 bpp, rgb or bgr
does not matter.
Afterwards sdl creates a SDL_Surface from the given DisplaySurface and
blits it into the main SDL_Surface using SDL_BlitSurface.

Look at: sdl.c:sdl_setdata and sdl.c:sdl_update.

Everything is handled by sdl transparently.

No I didn't test it with a real bgr display ;)