> > 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. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
