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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel