From: Hartmut Niemann <niemann@cip.e-technik.uni-erlangen.de>
  To  : ggi Mailingliste <ggi-develop@eskimo.com>
  Date: Mon, 13 Jul 1998 11:18:49 +0200 (MESZ)

Where do we stand now? (Re: Out of the chaos, and other threads)

Hi everybody!

Some are proposing new web sites, some are proposing new directory schemes,
and I feel we have had better concepts in the back than we have now, and
more ideas about what we are actually doing?

To add my 2 DPf, soon to be 0.0108 EUR:

To me, and that is surely an opinion, the GGI project is still one 
project. It has several branches, but one goal:

    Bring quality graphics to all computers!

This is where we started, this is where our key competence lies, but we're
not half way where we want to be.

Our first goals were:
- secure graphics to linux (and all OSs we find developers interested)
- as fast as possible
This still holds true, doesn't it?

Fast and secure graphics means: some kernel part, some userspace.
We wanted to draw the line on a per-card-basis, so we have a 
(kernelspace) driver and a (userspace) libggi (vendor) library.

To make that work, we need one API on top of that, which we call now
libggi. The core libggi, and the hardware independent targets, like
X, are functional, but need some fine-tuning and polishing. 

The driver side doesn't look too bad either, although not much maintenance
has been done there. 

Both tie together in accelleration support, and here lots of work need to
be done, but not at first priority, see my reasons below.

The drivers themeselves are (by design decision) mostly os independent,
should depend ONLY on the hardware driven, and the intention is to make
them fully independent (except from the target HW, of course, so that the
Millennium driver can, from one source , drive a Millennum in a PPC PCI
system, an Alpha with Digital Unix, a NextStep Intel PC ...

This is/was our design goal once, and it (IMHO) still is.

To make that work, we need to provide a glue layer between the drivers
and the underlying OS/hardware, and here most of our current confusion
comes from. Not only PCI services and inb()/outb() macros must be
provided, but some OS glue is needed.
We have a KGI, which drives the complete linux console and tries to
handle everything.
We have EvStack, which does the same in an even mode generic way and
will fix the 24-hours-per-day problem too :-).
We have the glue layer that interfaces our GGI drivers with the generic
Linux (orig: -68k) frame buffer,
some might find other platforms. (Generic Win98 graphics drivers, anyone ??)

One major problem I see with the current development is, that the 
KGI and the EvStack and the fb team/developer have different requirements
and interfaces for the drivers, and thus maintain their own driver
source tree.
And nobody knows what Steffen's driver API changes will be ... :-(

I doubt that this development effort can be afforded much longer.

Although I know/believe that the linux console management should be
cleaned up, I don't think we should provide three solutions.
I don't think either that we should try to implement SpaceOrb support
into that glue layer/console things... 

We have decided on some major libggi API changes lately, that have to
be implemented now. Here (hopefully) no major redesigns will happen.

We should have learned enough by now to come to a 'final' driver API,
provide one glue layer for each OS we want to support, and make all the
drivers work again. What gain do we have from a glue layer (i.e. console
management system) that allows us probably to use all nifty features the
drivers which are to be written will have? Wouldn't it be better, at least
as a short term solution, to take the lesson we learned from creating
EvStack, to provide a driver API that makes these things possible, and
then concentrate making the drivers possible?


For me a logical structure for our development team, for the web site
and for the file tree would be:


/lib/libggi
/lib/libggi2d
/lib/libggiXAA
....
/driver/IBM/
/driver/S3/
....
/platform/linux/framebuffer
/platform/linux/GGIConsole
/platform/linux/KGI            or fade that out ...
/platform/FreeBSD/...

And if the driver API can not be integrated in such a tree model, I
suppose the API is not good enough.

Everybody of us must sit back and think what his/her (any ladies reading?)
goals in this project are. We all want to make this product good, but we
can only if we know what 'good' means to us.

There has been much talking and much coding lately, but has there been
a fair amount of listening and thinking?

Thank you for reading. 

Hartmut.
--  
Hartmut Niemann   --   niemann(a)cip.e-technik.uni-erlangen.de
http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi]