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=
> visual. It would help if applications were written to expect a fourcc cod=
> 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 =
> rgb framebuffer at the kernel level using the "recently" merged deferred =
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
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 <daniel@...>