From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FSzSK-0005p6-7K for qemu-devel@nongnu.org; Mon, 10 Apr 2006 12:41:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FSzSI-0005ou-9M for qemu-devel@nongnu.org; Mon, 10 Apr 2006 12:41:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FSzSI-0005or-6P for qemu-devel@nongnu.org; Mon, 10 Apr 2006 12:41:34 -0400 Received: from [204.127.192.81] (helo=rwcrmhc11.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FSzWy-0001K8-0g for qemu-devel@nongnu.org; Mon, 10 Apr 2006 12:46:24 -0400 Message-ID: <443A8ABB.9010409@win4lin.com> Date: Mon, 10 Apr 2006 12:41:31 -0400 From: "Leonardo E. Reiter" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Updated BGR vs. RGB vga patch... References: <443A86FC.9010302@win4lin.com> <200604101735.39032.paul@codesourcery.com> In-Reply-To: <200604101735.39032.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paul Brook Cc: qemu-devel@nongnu.org You can definitely figure it out by asking the X server or SDL. I don't know enough SDL to have hacked it in myself. X is pretty simple on the other hand. As for where to add it, I agree that the low level conversions are not a great place to add this. I didn't originate the patch, I just updated it. Unfortunately none of the VGA is optimized - everything happens pixel by pixel already. Adding what probably amounts to 2 instructions (probably a couple of clock cycles) per pixel doesn't seem to do anything for performance really. The VGA is already slow. Unfortunately X11 will not allow you to force a certain color order in 24-bit mode. You can tell it to force byte-order but this only affects 16-bit blits - it's ignored for 24-bit since the individual components of the 24-bit blits, even if packed into 32-bits, are still 8-bits long. That's what the color masks are for. There is no efficient way to do this at the server level that I can see. If you find a better way (within the current scope of the VGA architecture), I'd be glad to try to implement it. I was just sharing something that was useful to me. Thanks, Leo Reiter Paul Brook wrote: > On Monday 10 April 2006 17:25, Leonardo E. Reiter wrote: > >>Hello, >> >>attached is an updated version (against today's CVS) of a patch to >>enable B/G/R color encoding rather than R/G/B with the command-line >>option -bgr. I found the original here (post by Martin Bochnig): > > > Shouldn't we be able to figure this out by asking SDL and/or the X server? > Also, adding an if to the low-level conversion routines seems a bad idea for > performance. > > Paul -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com