On Thu, 2010-12-09 at 13:41 +0100, Mark Kettenis wrote: > > From: Alan Hourihane <[email protected]> > > Date: Wed, 08 Dec 2010 08:50:00 +0000 > > > > On Tue, 2010-12-07 at 23:20 +0000, Matt Turner wrote: > > > On Tue, Dec 7, 2010 at 8:07 PM, Mark Kettenis <[email protected]> > > > wrote: > > > > No need for byteswapping in YV12 decoding on BE machines > > > > > > > > The hardware seems to do the proper thing already, so always use the > > > > same > > > > code on both little-endian and big-endian machines. Fixes xv YV12 on a > > > > TechSource Raptor GFX aka Sun PGX32. > > > > > > > > Signed-off-by: Mark Kettenis <[email protected]> > > > > > > Nice! Good catch. > > > > > > I suppose this fixes the problem you discovered in the other thread? > > > > > > I'll commit this. > > > > Might want to check the hardware manuals on this, but there might be a > > byteswap bit someplace that does it in hardware. The PGX32 may do this > > at BIOS init time, whereas a PC version may not. There is a bit for this > > on the PM3, so there maybe something on PM2. > > Well, obviously the PGX32 doesn't have a BIOS, but the Open Firmware > Forth code on the card might indeed do something like that. The > OpenBSD kernel driver for this card also twiddles some of the > endianness bits for the framebuffer windows to get things into the > state expected by the glint driver. The Linux framebuffer driver does > something similar, and I'm pretty sure NetBSD has something like that > as well. > > I don't have access to hardware documentation. Documentation was only > ever available under NDA isn't it? Do you expect there is a seperate > bit to set the ednianness used by the YUV transformation hardware?
Possibly. I can't remember. But it's worth checking because the code wouldn't have been added without good reason in the first place. > > Just thinking if you drop a PC card into a BE machine will it still > > work ? > > That won't work on OpenBSD/sparc64 (or OpenBSD/macppc), since the > kernel only supports graphics hardware that has an Open Firmware ROM. > The same is true for NetBSD as far as I know. Not sure what the > situation with Linux is. But I'd expect that as long as you use the > kernel framebuffer driver things would work regardless how the > firmware configures the card upon boot. Actually it will work (or should), not for the boot console - obviously, but for secondary cards it should work just fine. > Are there any other operating systems that matter here? Not sure what the OS has to do with the above though. Alan. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
