From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Mon, 10 Aug 1998 18:24:50 +0200

Re: Big changes to CVS tree

> >  * Removed ggi_visual->priv and replaced it with
> >    void               *targetpriv;    /* Target private data */
> >    void               *helperpriv;    /* Helper private data */
> >    void               *genericpriv;   /* Generic library private data */
> >    void               *hwdrvpriv;     /* HW-driver private data */
> 
> Do the "generic-linear-*" libraries use the "hwdrvpriv" one ?
> And what is genericpriv, is it just for "generic-stubs" ?
> 
> I'm also left wondering about things like "generic-ramdac" and
> "generic-ioctl".  Perhaps this can be integrated with ggiGetAPI(), e.g.
> a library with number #N can store it's private data in vis->priv[N] ?
> Hmmm, each library wouldn't know what #N it was though...  Bummer.

Well, that document was in no way meant to be some final documentation
of changes, it's just something I have to know what I've been doing
so far. We'll have to come up with a scheme to let driverlibs keep
internal data somewhere else than with static/global variables.
generic-stubs and generic-linear* shouldn't need any internal data
anymore now. But linmm, gamma, ramdac, ioctl does.

Anyway targetpriv was meant for targets, helperprivs for target-specific
helpers (ie helper-vgagl) and hwdrvpriv for hardware drivers like
the VGA and mystique drivers that were in dali.
generic was meant for ramdac, ioctl etc, but it obviously won't work
as they are almost always loaded simultaneously. Any ideas?

> >  * Removed LIBGGI_FB_LINEAR, added LIBGGI_CURREAD and LIBGGI_CURWRITE
> >    and made the default libs use those.
> 
> There is a problem with the app/priv separation.  For trueemu (and
> others), I want to load and use "generic-linear-*" libraries to do the
> actual drawing, but I also want the direct-buffers for each frame to be
> private.  Currently we have something like :
> 
>    #define LIBGGI_CURWRITE(vis)  (LIBGGI_APPBUFS(vis)[curframe]->write)
> 
> which would mean the buffers are always public.  In light of this, I
> think we should have just a single db array, where the first M buffers
> correspond to each frame (0 .. M-1), and an extra flag like
> GGI_DB_PRIVATE which causes those buffers to be skipped by the
> ggiDBGetNumBuffers() and ggiDBGetBuffer() functions.
> 
> Another thing...  so we can implement ggiSetDisplayFrame(),
> ggiSetReadFrame() and ggiSetWriteFrame(), we need three values instead
> of just "int curframe" in ggi_visual.  We could have :
> 
>     ggi_directbuffer *d_frame;   /* current display frame */
>     ggi_directbuffer *r_frame;   /* current read frame */
>     ggi_directbuffer *w_frame;   /* current write frame */
> 
> And thus :
> 
>     #define LIBGGI_CURREAD(vis)   (vis->r_frame->read)
>     #define LIBGGI_CURWRITE(vis)  (vis->w_frame->write)
> 
> How does this sound ?  [I'm happy to implement all this].

Yeah, I wasn't really happy with this either after some thinking...
d_frame, r_frame and w_frame sounds perfect. Using them will also
allow us to keep the app/priv separation, which I think we should.
I'd also be happy if you implemented this. ;-)

//Marcus