From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 3 Jun 1999 12:15:36 -0700 (PDT)

Re: GGIMesa updates/questions

On Thu, 3 Jun 1999, Andreas Beck wrote:

> > > Yep, this is ok except that the the latter two would begin with
> > > vendor-creative- for Jon's drivers.
> 
> > 	What info does the vendor-creative- part provide that an ident string
> > cannot?  And the ident string can map back to vendor-s3, generic-kgicommand,
> > or an infinite number of interfaces that haven't been designed yet!  
> 
> That makes no sense. The driver must be written to support those interfaces,

	Not at all.  The bridge code that translates the driver's native API
into whatever userspace API is being used is contained in that API's
kgi-savage4 (or whatever) target code.  I thought the whole point of the
target system was to be able to keep the kernel components (KGI drivers) as
lightweight as possible by this exact system. 

> so not-yet designed interfaces have only a very remote chance to be
> compatible with an existing driver.

	Right.  They all need "driver" libraries to do the API bridging.
 
> > do need a little extra userspace code to handle that mapping, but A) each
> > extension would only have to care about mapping the ident string to _its_
> > interfaces, 
> 
> ??? Why should these interfaces differ ?

	Because the APIs in question differ in their needs of the KGI driver,
and thus in the most efficient way(s) to represent the KGI driver's state.
 
> Interfaces do _NOT_ describe any external interface toward the user, but
> only the Intraface between the LibGGI(-extension) module and the card
> driver. 

	Correct, and that will vary from extension to extension.  It should
be the library's responsibility to do the API bridge, not the driver's. 
Unless, as I said, we get a KGI-dynamic which can load and unload intraface
handler/implementor modules at runtime.  If we had a system like that (which
I have thought a lot about recently as it would be very useful), your way
would be better because the KGI driver could directly export dynamic APIS
just as LibGGI does.  But wo do not have such a system at the present time,
and thus all the interface handling code has to be statically linked into the
driver, leading to bloat.

> It just says something like "to send a command, use kgicommand(...)"
> or "this card exports an S3-style MMIO area with registers".

	Or:

* This card can double/triple-buffer
* This card has a z/w-buffer with xxx bits of precision
* This card exports x number of tiled apertures, each with a different 
  possible stride/bitdepth/etc
* This card can map texture and/or vertex buffers with a wide range of 
  possible parameters
* This card has a command fifo which can be mmap()ed to userspace
* This card can draw single triangle/strips/fans/quads in hardware

	...and this list goes on, and on, and on.  And it will continue to grow
as new cards with all sorts of wacky types of features hit the market.
 
> > B) you don't need to manage a fixed set of interface strings.
> 
> This is a natural process:
> When you write a new driver and you see it is 100% compatible to the older
> one for the functions supported there, plus a few new ones, you just keep
> exporting the old API-strings and add a new one for the new functions.

	And in five years you have a hundred strings to support.  Drivers
should be written, debugged, and then left alone.  The userspace code is what
is flexible - it should bear the burden of bridging an extension API to the
KGI driver.
 
> > > > > _ggiAddAPI(ggi_visual_t vis, const char *api):
> > > > Why should one add an API later ? Because the extension might 
> > > > be needed to detect it ? 
> > > Because I don't think you can convince the fbdev people to start
> > > using suggest-strings for normal fbdev drivers. ;-)
> > 	Or Glide, or X, or VNC, or....
> 
> These can be handled by the LibGGI "display" driver.
>
> Though I see reason for the AddAPI call (like the Mesa extension detecting
> GLX), and we should do that change.

	Cool.  The rest of this discussion is interesting but this is what is
preventing me from getting a working display/ subsystem in GGIMesa so it is
kind of urgent right now.
 
> Chained list of API-strings ? Modification functions like:
> 
> _ggiAPIAdd   (ggi_visual_t vis, struct API *what_to_add, struct API *after);
> _ggiAPIDelete(ggi_visual_t vis, struct API *what_to_delete);
> _ggiAPIGet   (ggi_visual_t vis, int number);
> 
> for convenience ?
> 
> We will want to count APIAdds in case multiple extension want to add the
> same API string.

	In LibGGI3D, the same interface can have different implementations. 
How will we handle this?  Will it even be possible?

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed