> Is a complete _detailed_ documentation available about _how_ the GGI
> target-system works and is handled in the code?
Umm - that's a bit much, as this is a "coders only" question, so I'll keep
to showing a quick rundown. If you want to code, you will start at some
similar target anyway, if not, it would be wasted time to go into much
details.
> The sources only offers this structure to me:
> [snip]
Correct so far.
O.K. - the inner workings of the target system are as follows:
When ggiOpen is called, the given arguments are parsed, and the resulting
display-string (which may be autogenerated, if NULL or "auto" is given) is
split into target and arguments and argptr is read from the parameter list.
These parameters are fed into _ggiOpenDL, which will load the DLL that
is described in its "target" argument. This effectively calls into
_ggiAddDL.
_ggiAddDL looks up the target in the GGI config file and then tries to load
the dll that is found there using _ggiLoadDL. If this returns success, it
will register the DLL at various places, depending on the supported
operations in this DLL.
_ggiLoadDL will open the module using the generic helper lib call
ggLoadModule. It will then try to look up a symbol called
"GGI_SYMNAME_PREFIX""basename(dll_filename)". This is the single
entry point into the DLL. The complex name has been chosen to make
it unique to allow for statically linking LibGGI.
This function will then be called 3 times to get vectors to the open, exit
and close functions which will be saved for future reference.
The function is a stub in the DLL only used to get other function's
adresses. This has the advantage to have only a single entrypoint. The
function itself usually looks like this:
int GGIdl_targetname(int func, void **funcptr)
{
switch (func) {
case GGIFUNC_open:
*funcptr = GGIopen;
return 0;
...
The saved open functio is called back in _ggiAddDL and it has to return
sucess in order to really load the lib. If it returns failure (like when
unable to detect the subsystem the target should run on), the ggiOpen call
fails.
At this point, the first call into the actual DLL is made. It takes the
arguments vis, dlh, args, argptr, &dlret.
vis is a reference to the visual, dlh kind of a "self" pointer to the dll
handle entry, args and argsptr are the given arguments, and dlret is an
extra returncode, that does indicate which subsystem (color, gc, ...) the
given DLL handles.
The DLL should parse its parameters, check them and check itself for
suitability (like detecting hardware) and then hook its stuff into the
LibGGI call tables like this:
vis->opdisplay->getmode=GGI_file_getmode;
Note, that it does not need to hook everything at this time. It can hook
indivisual stuff later, and it usually does so at setmode time, either
explicitly, or by postloading rendering libraries like linear_xx.
The hooked functions are pretty much all virtualized versions of the normal
LibGGI API.
Hope that answers a bit. Maybe someone wants to integrate that mail into the
technical docs.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
