"Jon M. Taylor" wrote:
> Antonio Campos wrote:
>
> > 1) Installing KGI is not an easy task. (It only supports a few cards).
>
> _Running_ KGI is not an easy task, because it only supports a few
> cards. Installing it is actually pretty easy, unless you don't already
> know about kernel development issues in which case it would be _very_
> difficult. KGI is not meant for the end user yet, although it is close
> than you might think.
This is correct but also to some way intended. I have concentrated on getting
the framework and concepts worked out, not to write as many drivers as possible.
> > 2) It doesn't expose a way to handle 2D and 3D graphics in an unified
> > (inside kernel) way.
>
> Yes, it does. Read the docs, please.
To what I only like to add that they may be found at http://kgi.sourceforge.net
...
> > 3) It doesn't handle the resource allocation of buffers (framebuffer
> > memory (back and front, double and triple buffers, etc.), stencil
> > buffers, and the like...)
>
> Yes, it does. Or rather, it provides support for resource
> allocation of abstract buffer types, and the individual KGI drivers
> themselves map out whatever buffers their hardware provides.
It does handle mode specification and initialization of almost all buffer
formats I know. Even more. You can specify z-buffered modes, whith/without
alpha channels, overlays, stereo, anything you can think of.
E.g. initialization of a double-buffered 16bpp stero mode with 16bit z-buffer
works fine with the Permedia2 driver.
However, splitting resources is not yet addressed by KGI-0.9, but is planned
once I have an accelerated X server going.
So, in that way we are in the right direction (though not yet really there
where we want to go).
Steffen
_______________________________________________________________________________
Steffen Seeger mailto:[EMAIL PROTECTED]
