Index:
[thread]
[date]
[subject]
[author]
From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
To : ggi-develop@eskimo.com
Date: Thu, 29 Jul 1999 14:20:58 -0700 (PDT)
Re: 2nd prerelease: EXTENSION HOWTO and EHelper
On Wed, 28 Jul 1999, Brian S. Julin wrote:
>
>
> I finally got things kludged together enough to do a prerelease.
[snip]
> Third, for some reason for extension foobar under X, which
> was my test environment, "display-x-foobar" gets loaded
> before "generic-linear-8" and "generic-stubs", which makes
> it kinda hard to overload the generic-* libraries...
Yep. I had the same problem in GGIMesa. LibGG apparently tries to
extend the GGI_DISPLAY target variable and load that first, regardless of the
order of the libraries listed in the .conf files. What I had to do to fix
this was to change the behavior of the sublibs so that they could go off, try
to load a valid rendering subsystem underneath themselves, and if sucessful
(checked by seeing if function pointer hooks == NULL) the top-level sublib
loader would stop enumerating and trying to load any more sublibs.
Basically an in-order tree traversal.
This way, the generic-stubs and generic-linear-* libraries will not
even be looked at unless the display-x-foobar returns without having
successfuly created a valid target-specific rendering setup, which is as it
should be. But it requires a bit more intelligence in the sublibs themselves
to properly manage the sublibs underneath themselves. If at any level it is
possible for a loaded sublib to partially implement the interface of the
level above it, this must be explicitly accounted for or everything will get
thrown away when the sublib does not implement the _whole_ interface.
All I had to deal with was the setup below, which was not too complex on
its face, and it still took quite a bit of tweaking in order to get
everything to coordinate properly.
The sublib tree for GGIMesa on my system looked like this:
GGIMesa top level
generic-stubs-mesa
generic-linear-*-mesa
display-fbdev-mesa
tgt-fbdev-kgicon-generic-mesa
tgt-fbdev-kgicon-savage4-mesa
So, when GGIMesa was attached to a visual, it would first check to
see if a target-specific library was present and immediately fall back to
generic-stubs or generic-linear if not. If one was present (fbdev only
for now), it would check to see if a KGIcon driver was loaded. If not,
it would look to see if the plain fbdev driver had an accel lib (like the
LibGGI matroxfb accel driver). I never coded any support for this since
I have no matrox card, but the framework was present. If this also
failed, there would be nothing for the fbdev "driver" to do, so it would
exit without hooking any of the API calls, the top-level GGIMesa GetAPI()
call would see this and once again it would fall back to stubs.
If a KGIcon driver was present, the fbdev driver would load the
kgicon "accel" helper, which would in turn do more or less what the fbdev
library above it did - probe for a specific driver type, see if an
associated helper library was present, and bail out if not since there
would be nothing for the kgicon helper to do, which would jump back to
the fbdev target, which would in turn jump back to the top level without
having hooked a valid driver, which would once again fall back to stubs.
Only if the kgicon helper found a Savage4 (which it had to probe for
itself!) would it load the Savage4 helper which would hook the API calls,
jump back to the kgicon helper, jump back from there to the fbdev target,
and jump back from there to the top-level which would _NOT_ load the
stubs or generic-linear libraries (or any others), since the fbdev driver
returned having hooked a valid rendering system.
> the latter two are loaded in the right order so that stubs
> is overloaded by linear-8. My guess is this has nothing
> to do with the foobar extension's code though...
Yes and no. The primary reason is that LibGG tries to load a
target-specific extension sublib first. The secondary reason does have to do
with the extension code, however - as you can see, sometimes the process of
autodetection and intelligent loading of the hierarchical library system
cannot be done correctly without adding more intelligence to the extension
code.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Index:
[thread]
[date]
[subject]
[author]