On Fri, 9 Feb 2001, Christoph Egger wrote:
> > Yes. LibMISC would use LibGAlloc to find out if (or demand that)
> > any of the miscellaneous features that it provides an API for are
> > available on the target along with the desired video mode.
>
> So it can be used as an example code for the others extensions,
> right?
Well -- not yet, because LibGAlloc doesn't exist, and because
the MISC extension was written before the current "standard" and
has not been rewritten to be like the newer extension.
> > > > Lib3DMem - 3D textures, AGP, Z-buffer, etc.
> > >
> > > Does libxmi fit here as well?
> >
> > Libxmi would use Lib3DMem to allocate it's VRAM, but It's a
> > pseudo-wrapper library which is quite a lot more than a "feature
> > API implementation"; listing it "under" LibGAlloc didn't really
> > do it justice.
>
> Please explain "pseudo-wrapper".
A "wrapper lib" is a library that puts a new face on the GGI(+extensions)
functions to make it take the place of an existing library, like
libmi or libsvga. But libxmi is more of a "feel alike" API, not
a drop-in replacement for libmi.
> To not lose the stuff libOVL should handle, I want to sum up:
>
> It (de)allocates resources for sprites, video overlayers and generic
> window overlayers like YUV viewports. Furthermore it displays the
> layers _only_ in hardware. Anything else is handled by higher/other
> libs.
>
> OK, so far?
Actually, that's backwards. LibGAlloc can be used to request either
a real overlay, or some RAM to use instead of a real overlay. Either
LibOVL (or libBSE when called by LibOVL) would request a real overlay,
and if it could not get one it requests the RAM instead and implements
the get/set functions.
Now that I think of it, we'll have to add this:
#define GGI_FT_DIRECTBUFFER 0x40000000 /* there is direct MMIO access
to the feature's data */
...because GGI_FT_MEMVIS is really for when you specifically _want_ to use a
memory visual.
> If yes, then I think that those "features" makes sense in libOVL:
I think they make sense in any case -- except for GGI_FT_FRAME, which
is meant for apps trying to set up backbuffers.
> > What I'm referring to is a 26 pin header or 2x13 edge connector
> > on older SVGA cards that used to be used to plug into video
> > capture cards and off-board 3d graphics processors like the
> > original 3dfx cards. Some of the SVGA cards would just turn off
> > the whole screen and let the data from that connector run through
> > the CRTC. Others would actually allow you to define a window
> > where the data would show through instead of the VRAM data.
>
> But this _not_ the job of LibOVL...
If libOVL does motion video, then it is. If not, then not.
--
Brian
