xclock/oclock endian mismatch in Xfbdev [SOLVED]

Dushara Jayasinghe dushara.jayasinghe at hydrix.com
Mon May 16 17:49:55 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
>>> 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.
>
>
I had a look at the pixman code but what's required to add the format 
that suits the hardware is not immediately obvious to me. The CPU 
peripheral is configured as 1bpp (packed). The MSbit is the left most pixel.

I'm guessing that I have to invent a new pixman type (maybe 
PIXMAN_TYPE_AREV) and add a format to the list in pixman_format_code_t 
pixman.h. And finally implement the handlers (yet to figure that out) 
that use the formats. Please tell me if I'm on the wrong track.

Thank you
D


More information about the xorg-devel mailing list