gc-linux-devel

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

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

Hi Folks

I've been fiddling again looking at porting a few more frame buffer code
to operate with the 'cube not-RGB frame buffer. It struck me that
instead of lying about the visual reporting it with a fourcc code would
be quite useful for detecting and adapting to strange pixel formats (and
the resulting code could be ported to other weird hardware without
conditional compilation).

The attached patch shows what I have in mind.

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

Re: [Gc-linux-devel] =?utf-8?q?gcnfb=3A_Report_the_visual_using_an_ap?= =?utf-8?q?propriate=09fourcc_code?=

[Albert H. <alb...@ya...>]

Daniel Thompson writes:

> I've been fiddling again looking at porting a few more frame buffer code
> to operate with the 'cube not-RGB frame buffer. It struck me that
> instead of lying about the visual reporting it with a fourcc code would
> be quite useful for detecting and adapting to strange pixel formats (and
> the resulting code could be ported to other weird hardware without
> conditional compilation).
> 
> The attached patch shows what I have in mind.
> 

Hi Daniel,
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.

Maybe if the standard Linux kernel starts using a fourcc to specify a visual
then we could use it in a useful way.

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.
 
Cheers,
Albert

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...>