[Xorg] Re: DRI fixes for libdl module loader

[Keith Whitwell]

Adam Jackson wrote:
> -----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