On Wed, Oct 12, 2022 at 04:31:14PM +0200, Thomas Zimmermann wrote: > Hi > > Am 12.10.22 um 15:12 schrieb Arnd Bergmann: > > On Wed, Oct 12, 2022, at 2:00 PM, Thomas Zimmermann wrote: > >> > >> Could well be. But ofdrm intents to replace offb and this test has > >> worked well in offb for almost 15 yrs. If there are bug reports, I'm > >> happy to take patches, but until then I see no reason to change it. > > > > I wouldn't change the code in offb unless a user reports a bug, > > but I don't see a point in adding the same mistake to ofdrm if we > > know it can't work on real hardware. > > As I said, this has worked with offb and apparently on real hardware. > For all I know, ATI hardware (before it became AMD) was used in PPC > Macintoshs and assumed big-endian access on those machines. At least mach64 class hardware has two frame buffer apertures, and byte swapping can be configured separately for each. But that means you only get correct byte swapping for at most two bpps at the same time (and that only if you know which aperture to access each time). IIRC Rage 128 already has the surface register stuff where you could byte swap a limited set of ranges independently. And old mga hardware has just one byte swap setting for the whole frame buffer aperture, so only one bpp at a time. That kind of horrible limitations of the byte swappers is the main reason why I wanted to make drm fourcc endianness explicit. Simply assuming host endianness would end in tears on big endian as soon as you need to access stuff with two bpps at the same time. Much better to just switch off those useless byte swappers and swap by hand when necessary. -- Ville Syrjälä Intel
