On Tue, 21 Nov 2000, Antonio Campos wrote:
> Steffen Seeger wrote:
>
> > Antonio Campos wrote:
> >
> > > People want an OS for accesing the hardware in a clean, fast and reliable way.
> > > That includes the graphics hardware. And I must say that this handling is one of
> > > the most important tasks in modern operating systems (and one of the things that
> > > the user sees more quickly). And this handling is one of the things that Linux
> > > users can't feel pride about.
> > > We have that strange and quite limited fbdev kernel hack, the slow and
> > > uncomfortable to program Xlib (DGA, DRI, etc...), and of course, an ununified way
> > > of handling 2D and 3D graphics...
> > > I hoped the GGI/KGI project filled this gap (the same way I hoped the Alsa+OpenAL
> > > projects would deprecate the OSS sound drivers in an unified sound system), but
>it
> > > seems to me that is not going in the right direction (I'm sorry about saying
> > > this).
> >
> > So, in your opinion, what is wrong about the direction KGI is heading to?
> >
>
> Maybe I should have said that GGI is going in the wrong direction, not
> KGI. Anyways I
> don't know KGI or GGI internals very well, but it seems to me that:
>
> 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.
> 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.
> (Maybe I'm misunderstanding something, and this is the task of GGI,
> etc...)
No, it is the task of KGI.
> 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.
> Just to name some holes I see...
> front), stencil,
KGI_A_STENCIL is clearly defined in kgi.h, and the Permedia driver
uses it.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
