xclock/oclock endian mismatch in Xfbdev [SOLVED]

[Soeren Sandmann]

Dushara Jayasinghe <dushara.jayasinghe at hydrix.com> writes:

>> I'm Working on an iMX.25 (ARM) based embedded platform with
>> xserver_xorg-server-1.7.5.
>>
>> I had to make the following mods to servermd.h to reflect the hardware.
>>
>> #define FBNOPIXADDR
>> #define IMAGE_BYTE_ORDER	MSBFirst
>> #define BITMAP_BIT_ORDER	MSBFirst
>>
>> This setup works with xlogo and oclock (The image looks correct). However
>> when running xclock and a 3rd party gtk based app, the BIT/BYTE_ORDER is
>> incorrect.
>>
>> Are there instances where these defines are ignored? Any ideas on where I
>> should start looking?
>
> Ok figured it out. It stems from the fact that the CPU endianness (arm
> being LITTLE endian) doesn't match the endianness of the LCD
> peripheral (big). So even though I configured the FB, pixman was
> setting the endianness via the configure script. Which brings me to my
> next question, shouldn't pixman, xserver (and anything else that I may
> not have encountered yet) have this setting configured in a single
> place?

Generally, pixman should be compiled with the endianness of the CPU, not
of the framebuffer. There could easily be code in pixman that depends on
the endian-ness of the CPU for other things than swapping color
channels. If compiled with the wrong endianness, such code will break.

The right way to deal with framebuffers with the opposite endian of the
CPU is to add new swapped formats, not to compile pixman with the wrong
endianness. For example, the b8g8r8a8 format was added to deal with the
a8r8g8b8 format on a framebuffer that was endian-swapped reletive to the
host it was attached to.


Soren