Re: [Gc-linux-devel] gcnfb: Report the visual using an appropriate fourcc code

[Daniel T. <da...@re...>]

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 cod=
e, 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.

--=20
Daniel Thompson <da...@re...>