xclock/oclock endian mismatch in Xfbdev [SOLVED]

[Dushara Jayasinghe]

On 17/05/2011 12:08 AM, Soeren Sandmann wrote:
> 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.
>
Hi Thanks for the reply Soren,

I'll have a look at it again to see how I can fix it. Thanks again.