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
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e42f368.7030...@abeckmann.de
