On Wed, 17 May 2000, David Craig wrote:
> Y and UV are separated. Each 'pixel' is rendered (by a TV) using a Y signal
> in combination with a UV signal. A loose parallel would be to have a
> framebuffer of red values followed by a framebuffer of GB values. Where RGB
> pixel values are 'combined' by the video hardware to render a pixel.
> Does this mean planar will be no use to us as it is presumably used for
> interleaving framebuffer pixels?
AFAIK noone has made a true color plane target yet (vga 4 planar interleaves bits in
the CLUT table rather than color components) but GGI was built to handle it.
Basically it just boils down to making a skeleton target, teaching it how to find
the framebuffer and identify at what offest the planes start, and writing the
Get/Put Pixel functions and color mapping functions. Since it is a planar
format, you'll be wanting to implement Hline at least for performance reasons.
I guess what you may be asking is how to get the fbdev target to load the right
renderer for your buffer format. Normally this would be done by setting
the fbinfo so that the fbdev target can figure out what renderer to load, perhaps
adding a special case inside the fbdev target to map your format to a suggest-string.
However if the fbdev headers fall short and don't have a way to express
your format, you can either copy the fbdev target and make your own target for
this hardware, which is fine for an application that works only on a specific
embedded system if that's what you are doing. Or, you could look at the
kgicon or KGI options -- this would let you use the kgicon or KGI targets
(I don't know the operational status of the latter) which accept suggest strings
from the kernel module and have a better system for classifying buffer formats.
The disadvantage to that is you would have to write a kernel module for your
hardware other than an fbdev module. Given the way the api of fbdev is constantly
being haglled over and reworked, some would consider that an advantage though :)
As far as adding your special planar format to GGI/KGI/fbdev header files
so it has a proper name and definition, that can come later. It only really
matters for directbuffer users -- once the basic pixel and color functions are
implemented, any GGI program that was properly written and doesn't use
directbuffer should run on your target; many of the apps that use directbuffer
are written specifically for an RGB format, though, and they request that format.
Your target should refuse that request -- the program could still be run by using
a translation target similar to the truecolor emulation target. Those apps will
suffer from performance penalties, but that's what they get for using directbuffer.
--
Brian
