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).
2) It doesn't expose a way to handle 2D and 3D graphics in an unified
(inside kernel)
way. (Maybe I'm misunderstanding something, and this is the task of GGI,
etc...)
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...)
Just to name some holes I see...
front), stencil,
>
> Steffen
>
> _______________________________________________________________________________
> Steffen Seeger mailto:[EMAIL PROTECTED]
> TU-Chemnitz http://www.tu-chemnitz.de/~sse
