Re: gcnfb: Report the visual using an appropriate fourcc code

On Wed, 2008-01-02 at 23:21 +0000, Albert Herranz wrote:
> I can't see any advantage over the current solution in using a fourcc for the
> visual. It would help if applications were written to expect a fourcc code, but
> they aren't so you end up even in a worst situation.

It's not a great step forward. I just don't really like breaking the
applications that support GC (i.e. so they don't run on normal PPC). If
I get really precious about it I'm sure I could identify a 'cube from
files in /proc.

> On the other hand, one thing that I have in mind and could make linux
> applications directly useable using the cube's framebuffer is building a virtual
> rgb framebuffer at the kernel level using the "recently" merged deferred io
> framework.

Creating a virtual RGB frame buffer was my preferred solution for the
'problem' but it seemed easier to be efficient within userspace since
damage tracking is easier. I had not come across
Documentation/fb/deferred_io.txt before.

I'll have a good read of this, having a 'real' framebuffer
implementation is quite desirable to save a lot of userspace
conversions. It would be a great step on the way to good X with the
Xvideo extension (for efficient YUV access for decoders) which has long
been my ambition. I suspect I will never actually find the time to write
the Xvideo stuff though. Sigh.

-- 
Daniel Thompson <[email protected]>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Gc-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gc-linux-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBHfJXbrr8Ifkjg/MwRAo+pAJ9hbgRefCIfXZv2MLF/aSBxQF/N9wCeKUa4
Olz6vWveuYBvt6y6AaRikcI=
=Gs98
-----END PGP SIGNATURE-----