-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've got DRI and GLX working with the libdl module loader under current Xorg CVS. It works well enough to run glxgears (both direct and indirect) and quake3. The patch isn't quite finished, for two reasons. One, and rather trivially, since the GLX code is shared with X11.app and Cygwin/X, their indirect renderers need to be updated to match GLcore. This is effectively a one-liner.
The second problem is trickier. GLX is in principle independent of DRI; you can load it by itself and get just an indirect renderer in the server. The reverse is not true, since atm DRI's functionality is implicitly tied to GL contexts in the server. Clearly then, libglx has to load before libdri can do anything useful.
There are two ways of expressing this. libglx could load libdri as a submodule, the way it does libGLcore; or vice versa, libdri loads libglx. With the first method, we'd need a way to suppress loading libdri (no applicable hardware, or just the user doesn't want it). The 'omit' verb in the config file syntax is probably sufficient. With the second method, libdri becomes the top of the stack. I'm slightly in favor of the second method, one because it doesn't change the behaviour of existing config files, and two because it reinforces that DRI can be more than just a GL driver. (Not that anyone has taken that route.)
One of my goals with the libdl loader work is ensuring that the user can load any given module and it will work (if perhaps by doing nothing). Without one of the two proposed changes above, configs that say Load "dri" before Load "glx" will fail to start, and that's not acceptable.
Can't this be expressed with the native library dependency mechanisms of the OS? For instance, when you do 'ldd <somelibrary>', you get a list of other libraries it depends upon. Why can't we use this native mechanism to express the dependencies you're talking about?
Similarly, tasks like module init and module cleanup can be handled by native mechanisms (if you're not already doing this), rather than by bolting on new code around dlopen().
Keith
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
