xclock/oclock endian mismatch in Xfbdev [SOLVED]
dushara.jayasinghe at hydrix.com
Mon May 16 16:51:31 PDT 2011
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
>>> 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
>>> 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
> 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.
More information about the xorg-devel