BITMAP_BIT_ORDER in xc/programs/Xserver/include/servermd.h to fix endianness?

[Clemens Koller]

Hi There!

(Xposted to our small sm5xx-devel group for the sm5xx in kernel drivers)

I have a endianness problem with swapped colors on my silicon motion SM501
chip on PCI Bus of an embedded PowerPC processor (MPC8540).

I wrote a fb driver which just exposes the VideoRAM to /dev/fb0 in
32bit, 8bits per color.
If I manually copy bytes to /dev/fb0, I get the following color relationship.
FF000000 gives me a BLUE
00FF0000 gives me a GREEN
0000FF00 gives me a RED
000000FF gives me a BLACK (alpha) Pixel.
So, my framebuffer basically works fine with BGRa colors.

But, when I start X (i.e. 6.9.0) to use /dev/fb0
I get wrong colors on the display. It looks as X writes the
colors in an reversed aRGB order to the fb.

I've tried to tell X via the fb_var_screeninfo
structure all kind of 
static struct fb_var_screeninfo vgxfb_var = {
	...
        .bits_per_pixel = 32,
        .red            = { 24, 8, 0 }, //swapping the colors here doesn't affect X!
        .green          = { 16, 8, 0 },
        .blue           = { 8, 8, 0 },
        .transp         = { 0, 8, 0 },
	...
};
but it seems that X doesn't care about that at all.
Is that a bug in X or in my code?
Why doesn't care X about that?

So, after some research, I found out that in X's source in
xc/programs/Xserver/include/servermd.h:

----- 8< ----- snip!
#if defined(__powerpc__) || defined(__ppc__)

#define IMAGE_BYTE_ORDER        MSBFirst
#define BITMAP_BIT_ORDER        MSBFirst
#define GLYPHPADBYTES           4
#define GETLEFTBITS_ALIGNMENT   1

/* XXX Should this be for Lynx only? */
#ifdef Lynx
#define BITMAP_SCANLINE_UNIT    8
#endif

#define LARGE_INSTRUCTION_CACHE
#define FAST_CONSTANT_OFFSET_MODE
#define PLENTIFUL_REGISTERS
#define AVOID_MEMORY_READ

#define FAST_MEMCPY

#endif /* PowerPC */

----- 8< ----- snap!

...there is a way to change the BITMAP_BIT_ORDER from MSBFirst to LSBFirst.

Well, is this the right place to swap the endianness of the Xserver?
Is there a performance issue when X swaps the colors to the framebuffer?
(PowerPC's can just use a different store instruction, so no speed penalty
would be envolved if properly used... how can I check that?)

In above code: What does "Lynx" mean, here?
Is that a special case for Silicon Motion's Lynx graphics chip series?
This code seems rather old... hopefully somebody still knows...

Remember: I don't use the native X siliconmotion driver. I (still) use
a framebuffer driver. So above effects could be tested with
every other fb as well.

Thanks,

-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19