Ok so the problem is byte swapping. Looking at atyfb for example it uses 
the "big-endian" aperture on big-endian systems and selects the byte 
swapping method according to the bit depth. If that really means that all 
host access to the aperture gets byte swapped then I don't see how the 
current situation can work correctly for DirectFB. Offscreen surfaces can 
use any bit depth and so their bytes could be swapped incorrectly. Makes 
me wish I had a PPC box alongside the x86 one.

Possibly yes. In X, when blitting to an overlay surface, we
save/clear/restore the swapper indeed.

I would really like to keep the swappers independant though. Take things
like MOL (MacOnLinux). I maps the framebuffer and passes it to MacOS,
which expects proper swapping and doesn't (for a basic non-accelerated
framebuffer, which is what MOL implements) provide an easy way to
set/restore the swapper.

Also, doing so would require arbitration between clients using both
heads, while 2 independant swappers mean that even if the client wants
to temporarily disable it (for uploading an offscreen surface for
example), it has it's own swapper and won't conflict with whoever is
using the other framebuffer.

That means some knowledge about those swappers of course.

Note that almost all fbdev's on big endian platforms have some kind of
swapping mecanism on accesses, so that's something you'll have to deal
with anyway.

Ben.