[PATCH xf86-video-glint] No need for byteswapping in YV12 decoding on BE machines

[Alan Hourihane]

On Thu, 2010-12-09 at 13:41 +0100, Mark Kettenis wrote:
> > From: Alan Hourihane <alanh at fairlite.co.uk>
> > 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 <mark.kettenis at xs4all.nl> 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 <kettenis at openbsd.org>
> > > 
> > > 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.