On Wed, 11 Jul 2001, Aleksandr Koltsoff wrote:
> First of all, thanks for all the ppl who replied to my status inquiry about
> GGI.
NP
> But to the subject, as I understand (correct me if I'm wrong), DirectFB
> already contains some functionality which mirrors some of GGIs abilities?
Yes, but the API is weak, and contains no resource check/set routines, so
we cannot make a LibDirectFB target, instead we will be having LibGGI
pretend to be LibDirectFB and talk to their driver modules directly.
> So, if/when I'd write some application that needs direct and hw-accelerated
> access to the gfx-system (it will be the only application running on that
> card, however my application involves multiple cards in one system) which
> API should I use? I think that directfb also uses the fbdev-interface, so in
> connection to the previous question, would I be best off if I wrote a
> fbdev-driver for the SMI?
DirectFB + fbdev might be a good way to go, but binary-only drivers for
fbdev will not be accepted. KGI will accept binary-only drivers, I think,
ask Steffen. However KGI will require a patched kernel. I wouldn't tell
my worst enemy to write an X driver (ecch!).
Just if you do implement an fbdev driver, do it right -- after copying
the skeleton most fbdev driver authors leave some features in a state where they
say they exist, but are actually not implemented, e.g. ypan.
Mostly I would advise you to keep what code you can disentangled from any
individual project -- even if you have a DirectFB driver, when we start
doing high speed accel pushing, you will find that function call overhead
slows the DirectFB driver down, so if your chipset code is well separated,
implementing a fbdev direct accel target for LibGGI, or a KGI driver
will be much much easier.
> And what is KGI anyway?
It's explained pretty well on their SourceForge pages :-)
> years ago ;-) I did some work with GGI and then the KGI contained drivers
> for different hardware. Is it parallel to the current fbdev-drivers or
> something else completely?
Similar to in some ways, but more secure and hence theoretically more stable.
--
Brian
