Official method for determining modular X module path?

[Andy Ritger]

On Wed, 30 Nov 2005, Mike A. Harris wrote:

> Andy Ritger wrote:
> > With the new modular X server filesystem layout, how should 3rd party
> > vendors determine the path in which to install their X drivers?
> > My understanding is that the correct answer is for 3rd party
> > installation tools to run:
> > 
> >     pkg-config --variable=moduledir xorg-server
> > 
> > Is that correct?  If so, then I'd like to champion this with the
> > Linux distros.
> > 
> > The installer for the next NVIDIA Linux driver release will run
> > the above command; if that is successful and returns a directory
> > that exists, it will be used, otherwise the NVIDIA installer will
> > fall back to /usr/X11R6/lib/modules.
> > 
> > Is that the proper heuristic to use?
> 
> Sounds reasonable to me.

Great; thank you, Mike.

I think the moduledir variable was discussed on IRC, and a recent
Gentoo install defines moduledir, but a user reported that it is
not defined on Fedora Core 5 RC1.  Does the moduledir definition
in the pkgconfig *.pc files come from the Xorg modular build, or is
that something distribution maintainers will need to handle manually?

I'm nervous that this could be the kind of thing that would be easy
for a distro to overlook, and would only be exposed when someone
tried to install a 3rd party driver.

> One thing I'd like to see in 3rd
> party vendor's driver installers, is to have them install
> 'replacement' modules (ie: libglx.*) in a separate and
> nonconflicting location that does not overwrite OS supplied
> modules.

100% agreed.  I know that the current situation is broken/painful for
everyone. :(

The topic of vendor-provided files getting installed in
nonconflicting locations has come up before, and I'm definitely in
favor of it.

I had hoped that this would get hashed out in the Linux OpenGL
ABI discussion:

    http://base4.freestandards.org/pipermail/lsb-desktop/2005-September/000146.html

but that never came to a resolution.  It's on my todo list to try
to revive that.

You mention libglx, but I think that's an easier problem to solve;
suggestions I've heard (specific to NVIDIA, but could be applied to
any vendor) include renaming NVIDIA's libglx.so to libnvidia-glx.so,
or linking NVIDIA's libglx directly into the nvidia X driver.
We're planning to pursue that more in a future NVIDIA driver release.

The real problem case is libGL.  I know many would like to see
vendors just provide a backend module that loads into DRI's libGL.
For reasons mentioned in the above linked thread, that's not feasible
in the near term for performance reasons, but I hope we can revisit
that idea in a few years.

In the short term, a compromise to allow multiple libGL's to coexist
on the file system might be a system where:

    - distributions provide a simple utility (let's call
      it `/usr/bin/select-opengl.sh`; invoked, perhaps like
      `select-opengl.sh nvidia`).  Such a tool would:

        - update /etc/ld.so.conf so that the correct OpenGL
          implementation's directory was prepended to the library
          search path

        - symlinked /usr/lib/libGL.so.1 to the requested OpenGL
          implementation (to provide backwards compatibility for
          applications that dlopen() a specific libGL); this point
          might be debatable/unnecessary.

      We could provide a sample implementation of select-opengl.sh,
      but distributions would be free to implement it however they
      like, such as with environment modules, as suggested in the
      OpenGL ABI discussion mentioned above.

    - IHVs installing a libGL would check for the presense of the
      select-opengl.sh script; if it is present, then install the
      IHV's libGL in a vendor-specific subdirectory and run
      select-opengl.sh to make it "active"; if the utility is not
      present, then commit the same file system atrocities we
      do today.

Does that seem reasonable to you, Mike?  I know it doesn't solve
other problems, like lack of interaction with the rpm data base,
but it seems like a step in the right direction.

If you think the approach is OK, I'll try to writeup a spec and
a sample implementation for a 'select-opengl.sh' utility (better
names are welcome).  From there, we could propose it in the Linux
OpenGL ABI thread, and try to get buy-in from the major Linux
distros and my counterparts at ATI.

Thanks,
- Andy


> That's something that has been a troubling support problem for a
> while now, which I think would be useful for everyone to work
> together on a common solution of some sort, as this support
> problem impacts end users and distribution vendors negatively,
> and I have to assume that it also causes support problems for
> the driver vendor also.
> 
> Currently this can be done with ModulePath directives in the
> config file listing the vendor's module path first, and then
> falling back to the X.Org module path, etc.  It would be
> much nicer to somehow have this all happen automatic and not
> require configuration though.
> 
> Any thoughts as to how we might best proceed with such a
> solution?
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>