From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 20 Aug 1998 19:27:18 -0700 (PDT)

Re: libggi internals (Re: LibGGI3D RFC)

On Fri, 21 Aug 1998, Marcus Sundberg wrote:

> > > 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.

	OK, I think I understand. 

> > > 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 ;-/ 

	IIRC they are MMIO register softcopy sets, which are written to in
userspace and then sent to the kernel drivers and written out in one pass
(as opposed to userspace MMIO sets, one at a time).  A little safer (you
can control the timing of register writes if that is an issue), plus you
have a more narrowly defined kernel<->user window which leaves less room
for accidents. 

> > > 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.

	Fair enough.

> > 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, 

	At this point I favor a more evolutionary approach.  fbdev is the
established standard.  We might have more luck "upgrading" fbdev slowly
from the inside rather than coming in with a completely new KGI system all
at once.

> and I haven't heard
> anything about GGI Console since it was spitted out from CVS.

	It really is a completely separate project now.  I realize that it
is called "GGI console", but it really is disjoint.  So is KII, really.

> Anyhow we'll most certainly have to make a release before those
> things are done.

	Based on kgicon?  No problem with that, I am just wondering.  If
so, we need to get cracking on pushing acceleration ioctls through the
fbcon/fbdev interface.

> 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".

	What are the chances of LibGGI3D being part of 2.0?  It is
perfectly alright if that doesn't happen - I would *much* rather get 2.0
out the door on time.

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

	I have been flogging it heavily on linux-kernel, and will continue
to do so whenever the subject comes up (which, given fbcon, happens a lot
lately).

> 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"

	Yeah, I saw that post on Slashdot too |-<.

> >         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.

	OK.

> > 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.

	Interesting.  Nice to see a way to attach arbitrary data to a
visual.  Handy stuff, that.

Jon

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