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
/usr/lib/xorg/modules/linux/libglx.so
and leave
/usr/lib/xorg/modules/extensions/libglx.so
undiverted?
According to the source code and my tests, the linux subdirectory is
always searched first for modules and therefore suitable to install
"override modules".
Andreas
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
--
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/4e5373a6.2070...@abeckmann.de
