Bi Endian Support
What are Bi Endian Machines?
A Powermac with PCI/AGP uses a little endian framebuffer, while the host memory is big endian. This leads to some problems, which are not addressed in DirectFB yet.
What works? - The Endian Conversion Flags
Modern graphics cards have endian conversion flags, which can fix the incoming data from the host cpu/memory. For this purpose you can set 32-bit conversion or 16-bit conversion.
When transferring a 32-bit word in 32-bit conversion mode, incoming byte order is changed from 1234 to 4321 When transferring a 32-bit word in 16-bit conversion mode, incoming byte order is changed from 1234 to 2143
The linux framebuffer driver sets these flags accordingly when changing modes. This allows DirectFB to run on Big Endian Machines as if they had a Big Endian Framebuffer.
So, where is the problem, then?
When transferring 32bit surfaces from system to video memory, while running in a 16bit mode, the surfaces get crippled because:
When transferring a 32-bit word in 16-bit conversion mode, incoming byte order is changed from 1234 to 2143
Michel Dänzer wrote:
EXA (the new X.Org acceleration architecture) currently approaches this problem something like this:
* There are driver hooks that get called before and after CPU access to any pixmap stored in the framebuffer. * For cards that allow setting different swapping for different ranges of the framebuffer, these wrappers set up the ranges and swapping for the pixmaps. * Otherwise, if the pixmaps involved in the operation don't all require the same swapping, the wrapper that gets called before the access tells EXA to download the pixmaps into system RAM and do the CPU access there. This requires the driver to provide a way to download pixmaps that always works correctly of course.