Thanks,
Is XGGI targeted at directbuffer?
Regards,
David.
-----Original Message-----
From: Brian S. Julin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 18 May 2000 4:40
To: David Craig
Cc: [EMAIL PROTECTED]
Subject: RE: GGI support for non standard FB devices
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
