From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Tue, 1 Jun 1999 21:05:37 -0700 (PDT)

GGIMesa updates/questions

	New stuff:

* ggimesa.conf is now separately installed and opened, instead of 
.includeing it in libggi.conf, using LibGG appropriately.

* gears.c has been updated to use GGI_AUTO and renders directly to the 
primary display instead of rendering to a display-memory visual and then 
blitting to the primary visual.

* linear_24.so was not implemented correctly.  This should be fixed now 
but I do all my testing at 16bpp so I haven't had a chance to try it out 
yet.

* The new display/ subsystem is in place and integrated into the 
build/install system.  Currently it only contains kgi-savage4.c because 
there are no other accelerated GGIMesa targets in existence yet.

* Misc. internal regorganization/cleanups.


	Questions:

* I cannot seem to get kgi-savage4.so to be used by GGIMesa.  ggimesa.conf
maps 'display-fbdev-mesa' to the .so correctly (well it is a hack but...), so
kgi-savage4.so does get loaded and its ggi_dlinit() function is called
properly as well.  However, in spite of the fact that display-fbdev-mesa is
the last line in ggimesa.conf, ggiGetAPI() apparently insists on loading it
_first_, before generic-stubs-mesa and friends.  The end result is that the
GGIMesa private function pointers, which were initially set correctly by
kgi-savage4.so, get reset to the stub routines immediately afterward.  No 
other extension implements both default/ and display/ subsystems, so I 
have no example to look at in this situation.

* GGIMesa still handles the binding-together of GGI contexts (visuals) and
Mesa contexts (gl_ctx structs) outside of the LibGGI system, using:

GGIMesaCreateContext(),
GGIMesaDestroyContext(),
GGIMesaSetVisual(),
GGIMesaMakeCurrent(),
GGIMesaGetCurrentContext(), and
GGIMesaSwapBuffers().

now, the first urge I had was to turn all of this inside-out and bind the
Mesa context to the LibGGI visual instead of the reverse like it is now. 
That would enable me to make all those functions go away - context creation
and destruction would happen in ggiMesaAttach() and friends, SetVisual()
would be handled in an overloaded ggiSetMode() function, and SwapBuffers()
should be handled through the normal directbuffer routines anyway.  The
CurrentContext() stuff is a bit trickier to remove since OpenGL is an
immediate mode API and thus there is always one and only one global OpenGL
context in existence.  That'll have to stay, warts and all....

	However, I am not sure if the above is the best course of action.  It
might be the case that someone will want to be able to allocate a set of Mesa
contexts but only one LibGGI visual and switch the context mapping around at
runtime.  If the Mesa context is implemented as an extension private struct
(as all(?) other extensions handle their private contexts), one would need to
allocate multiple DB visuals and blit between them, which is what gears.c
used to do.  Not only is this a large waste of DB memory which is otherwise
not needed (the GL contexts holds the world data, all the GGI visual is for
is to tell it how and where to render), but it pretty much rules out a
LibGGI-based multipipe direct rendering system since you wouldn't be able to
render outside of a LibGGI visual context, which would force you to
soft-render to the temporary buffers or block, which defeats the whole point
of a DRI.

	Anyway, unless I am presented with or discover a nice clean way to 
resolve this, I think I am going to leave Uwe's API mostly unchanged.  It 
may not be as clean as the other extensions, but it does work pretty well 
so far.  If anyone who groks LibGGI internals better than I do could take 
a quick glance at the Mesa CVS code (they have anonCVS), that would be 
wonderful.  It is time for me to go home now....

Jon

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