Xorg module searchpath "override" directory

Andreas Beckmann debian at abeckmann.de
Tue Aug 23 09:32:22 UTC 2011

Hi all,

since I didn't get any feedback, yet, I'm asking again.

Are there any objections to installing the alternative slave link for
vendor implemntations of libglx.so as
and leave
According to the source code and my tests, the linux subdirectory is
always searched first for modules and therefore suitable to install
"override modules".


On 2011-08-10 23:08, Andreas Beckmann wrote:
> On 2011-07-25 19:03, Julien Cristau wrote:
>> On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote:
>>> libGL.so.1 is not the only file to be diverted, libglx.so is being
>>> replaced by the vendors drivers, too. Or is there some way of "search
>>> path magic" that would allow to place the "higher priority alternative"
>>> in a different location where it would be picked up before
>>> /usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
>>> the diversion here. Something similar to /lib/modules/*/updates/ ...
>> That shouldn't be too hard.
> I tried to look in the code (xorg-server (2:1.7.7-13)
> hw/xfree86/loader/* ; the experimental version does not differ much in
> that area) but didn't quite get how the search path is working.
> Therefore I added a bit debugging code to trace FindModuleInSubdir().
> Translating to pseudocode this now looks like
> modulepath=/usr/lib/xorg/modules
> for subdir in "" input drivers multimedia extensions internal
> do
> 	search_recursive ${modulepath}/${subdir}/linux/
> 	search_recursive ${modulepath}/${subdir}/
> done
> So the order the directories are traversed and files are found depends
> on the raw order in the filesystem (opendir()), except for the linux
> subdir which is checked first.
> hw/xfree86/loader/loadmod.c has
> /* Standard set of module subdirectories to search, in order of
> preference */
> static const char *stdSubdirs[] = {
>     "",
>     "input/",
>     "drivers/",
>     "multimedia/",
>     "extensions/",
>     "internal/",
>     NULL
> };
> but since a recursive search is done on "" first, the other directories
> in the list will be traversed (again and without hope of success) only
> if the first search was unsuccessful. So that "order of preference" is
> no more existant and the above pseudocode could be simplified to
> modulepath=/usr/lib/xorg/modules
> search_recursive ${modulepath}/linux/
> search_recursive ${modulepath}/
> Back to the original problem: replacing libglx.so with a vendor
> implementation without using diversions.
> I'd do the following:
> * leave /usr/lib/xorg/modules/extensions/libglx.so where it is
>   (i.e. no longer divert it)
> * the proprietary drivers register their libglx.so replacement with the
>   glx alternative which installs it as a slave link to
>   /usr/lib/xorg/modules/linux/libglx.so
>   so that it is picked up first and the original one is being ignored
> "linux" is acually OSDIR in the code and may have had a different
> intention, but it is the only deterministic place that is searched
> "before" extensions/libglx.so
> * no changes in Xorg needed regarding the search paths
> * works on both unstable and squeeze, so backports don't need special
>   handling
> If this is OK, I'll implement and test it and also verify that Xorg
> works in the same way in testing/unstable/experimental.
> That way, the first of the ugly diversions could be removed. :-)
> Andreas

More information about the pkg-nvidia-devel mailing list