From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Fri, 21 Aug 1998 02:36:55 +0200

Re: libggi internals (Re: LibGGI3D RFC)

> > An extension library is a library that needs to do one of the
> > following things:
> > * Access data that is internal to libggi.
> > * Change the behaviour of existing libggi API functions.
> 
>         This is a strict overload, right?  The symbol table is patched,
> and the new function's parameters and return value are the same as the old
> function's? 

Correct.

>         I'm still not clear on the difference between a new function in an
> extension and a new function in an application.  What makes the first one
> "part of LibGGI"?  What does "part of LibGGI" mean?

Have I used the term "part of LibGGI"? If so I made a mistake.
Basicly there are two kinds of functions:
Functions that only uses existing libggi functions to achieve something,
and functions that access the underlying subsystem directly.

An extension may provide both kinds of functions, or only one of them.
An application may only provide the first.

>         Ah, so targets are not rendering methods, targets are... well,
> targets |->.  The same target can have different rendering methods. 

Sure. For example the SVGAlib target can use either the generic-linear-*
libs, functions that are part of libvga, or load the helper-vgagl library
which uses functions from libvgagl, depending on if the svgalib mode is
linear, modeX or banked. And all three alternatives provides the same
functions, but implements them differently.

> > 3. Design a new kernel-driver API for your 3D drivers, which
> >    only deals with 3D.
> 
>         This might be necessary to flog the absolute most performance out
> of 3D hardware (ioctls == slow sometimes), but if this is to be done it
> should be saved for later, after we have something working first.

KGI is not limited to ioctls, it may for example allow applications
to mmap() the acceleration registers into userspace, or it may use
ping-pong buffers (I think, I don't even know what they are ;-/ 


> > The seccond option would be pretty braindead as KGI is already
> > about to be a standard. (Thinking of Alan Cox removing the
> > MediaGX driver and recommending kgicon instead).
>
>         Don't hold your breath |-<.  We may be using kgicon for a while. 

Well, kgicon _is_ KGI. It's wrapped inside fbcon, but it's still a KGI
driver, which is what I meant.

> We'll need to get Degas-KGI working and show that it is clearly superior
> and doesn't break things in the kernel before people will look at an
> alternative to fbdev.  Especially if kgicon drivers can be accelerated.

Well, I don't thing there'll be a "Degas-KGI".
Steffens new KGI is still in the design phase, and I haven't heard
anything about GGI Console since it was spitted out from CVS.
Anyhow we'll most certainly have to make a release before those
things are done.

My plans for libggi is that when Andy gets back it'll take maybe
two weeks to set the API in stone. Then a few more weeks to implement
it to 100% for the most common targets. After that it's time to relase
libggi Beta1, which will be announced on COLA. And I hope we can have
a rock-solid libggi 2.0.0 out by December, with a few targets possibly 
marked as "experimental".

As for kgicon we need to announce it's existance on COLA within a few
weeks to get more testers, and hopefully developers.

There are lots of people out there that doesn't know what GGI is,
and unfortunately also people that knows GGI as "the crap with the
ugly yellow blockcursor, which made everything on my system stop
working"

>         Ah, I see.  Now would there be only one type of ggi3dAttach(vis)
> for all possible permutations of 3D visuals (clipping, buffer layouts,
> rendering/texturing settings, etc?

There will be one *Attach function per extension, ie if you split
libggi3d up into more than one extension it will be more than one
*Attach function, or else not.

> If I want to draw to a depth buffer
> and then render from that to a 2D framebuffer, do I need a special
> 3D-but-really-2D framebuffer type or could I just use a LibGGI2D
> framebuffer?  That is, are the existing 2D visual attributes preserved
> with the 3D attributes "added on", or do you have to start from scratch?

A "ggi_visual_t" is the datatype returned from ggiOpen(), and it does
not in itself have anything to do with 2d or 3d. it's just a handle
that the application uses to refer to the thing being opened by ggiOpen().
Internally ggi_visual_t is a "struct ggi_visual" which contains all libggi
internal data, and also contains hooks where extension libraries may
attach _their_ internal data in such a way that it's associated with
a particular visual. This attachment of extension-private data is made
when you pass the visual to the *Attach() function of an extension.

I'm not sure if that last section answered your question, but I feel
that I'm entering the stadium where I'm starting to cunfuse myself
as I write, so if it didn't I'll try to do better after some sleep.. ;-)

//Marcus