> 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? > 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. Are there any other operating systems that matter here? _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
