On 17/05/2011 12:08 AM, Soeren Sandmann wrote:
Dushara Jayasinghe<[email protected]> 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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
