[Pkg-fglrx-devel] Xorg module searchpath "override" directory (was: Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations)

[Andreas Beckmann]

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