Official method for determining modular X module path?

[Mike A. Harris]

Andy Ritger wrote:
> 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?

The definition is from upstream, and is not a distribution specific
addition.  The variables changed slightly between X11R7 RC1 and
X11RC2 upstream, but I believe the current definition is probably
going to hold tight.

The user who reported this does not work on Fedora Core 5 is wrong,
it does work, and every single one of our driver packages use this
mechanism to discover the moduledir.  Pass me their IRC nickname,
and they'll be appropriately scolded and sent to the corner with
a book on their head. ;o)


> 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.

The 'moduledir' variable is created by the upstream source in
the pkgconfig file automatically without the distributor having
to do anything.  You would have to intentionally patch the source
to prevent the variable from being set, which I doubt any vendor
will do, because it provides a valuable thing to everyone, and
does no harm in the process. ;o)


>>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.

Yeah, it would be great if a generic solution would be developed
that is not distribution specific, and can be expected to work on
all systems.


> 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.

That would be a useable short term workaround, and it'd be nice to
see 3rd party vendors take this approach for now, but I think it'd
still be nice to have an X.Org provided 'standard' that could solve
the more general problem in a nice way somehow, preferably a drop-in
solution which did not require the user to custom edit the config
file, or for any config tool to be used to do similar.  The less
configuration needed these days, the better, so it'd be nice if there
was a generic out of the box solution that "just worked".


> 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.

Yep, I remember the discussions about that.  In order to make life
on 3rd party driver vendors, and the users of those drivers a bit
easier, I've made our libGL, and libGLU packaging split out into
separate rpm packages for a while now.  The solution in FC4 and
earlier allows the libGL rpm package to be uninstalled permitting
a 3rd party libGL to then be installed via rpm, which will automatically
"drop-in" without breaking the package management system or creating
unsatisfied dependencies.  The Livna.org nvidia rpms I believe work
well by taking advantage of this.  The only downside is that I did
not split out the development bits, so it was difficult to use 3rd
party development headers, etc. before within rpm packaging context.

For Fedora Core 5 and later, what I've done is split out mesa into
its own source rpm package, and each library contained within generates
a runtime package and a development package.  Now users of 3rd party
drivers can replace individual library components and their development
counterparts individually and still have a system that has proper
rpm package management, assuming the drivers they're installing are
provided in rpm format.  ;o)   I think this will make life that much
easier on users also, and I'm sure the Livna.org folks that repackage
the nvidia and other drivers will probably adjust their packaging to
take advantage of this change if they haven't already.

Another thing that we're going to do, is to move the config tool
hardware database metadata out of a centrally controlled database,
and directly into the driver packages themselves.  This way, when
you install a new driver rpm package, it installs a driver metadata
file into a common system directory which the config tool uses to
determine which drivers support which hardware, and let the user
choose which driver to use.  This will work in a manner not unlike
the .INF files used in Windows.  3rd party driver vendors or those
who package 3rd party drivers may then want to add the metadata
files to their driver packages, so that installing any driver,
makes it visible to our config tools, and simplifies the end user
experience of getting their system working without having to hand
edit config files.

Well, that's not yet implemented, but I'm hoping that we'll have
it in Fedora Core 5 test2.  Now that I've mentioned it publically,
I guess I've started the hourglass.  ;o)


> 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.

I think it's reasonable to have a generic solution of some kind
that allows switching between OpenGL implementations.  Additionally,
it would be nice to have a solution that permits co-existance of
multiple OpenGL implementations installed on the system and within
the package management system simultaneously.

We have a generic mechanism in our OS now called "alternatives",
which was a concept borrowed from Debian I think, however it has
not been used by many packages since we added it I don't think.

It is possible that we could develop some kind of standard wherein,
OpenGL implementations are expected to install into a namespaced
location in the system somewhere, and use the 'alternatives'
mechanism in order for a particular OpenGL to be selected. That
could be managed both from the commandline, and from the OS
installer, or config tools easily I believe.

If we went with a system like this, then in theory at least, from
a user perspective we might end up with:

1) User downloads foodriver.rpm from vendor and installs it.
    (manually using rpm, or using yum or apt or whatever)
2) The rpm installation of that driver package put the driver
    into a standard non-conflicting location, as well as any
    libGL, libGLU, and other modules, etc. also into non-conflicting
    namespaced locations somewhere.
3) The package also installed the aforementioned "metadata" files
    for the driver, so the config tools know where to look.
4) Some mechanism existed to inform the config tools where the
    OpenGL implementation or other files/etc. are located for this
    driver.
5) Now, the user runs the config tool, sees the "foodriver" show
    up because of the metadata file it installed.  The user chooses
    this driver, and confirms.
6) The driver now configures the X server to use this driver, and
    it uses the previously mentioned 'alternatives' system to
    configure which OpenGL implementation to use as the system
    OpenGL.  That information is derived either from the driver
    metadata file, or from some other mechanism that could be
    devised easily enough.

Now, their system has multiple GL implementations installed that
don't conflict, multiple drivers, and the system config tools
allowed them to set it up without editing a file, or messing
around.  Later, if they change video hardware, or want to try
some other driver, they run the config tool, choose the other
driver, it reconfigures the X server and uses the alternatives
selector to choose the proper OpenGL implementation for the
selected driver.

The only problem I see, is mixing hardware.  What happens if
you have say, an ATI Radeon card, and an Nvidia GeForce, and
want to set up multihead with acceleration?  I'm not sure if
this is something we should expect to work or not, or wether
it's something anyone supports (or wether anyone would want
to support it), but it's a scenario I thought I'd mention in
order to see what people's thoughts are, since if we're going
to try to solve the problems with driver installation and
configuration, we might as well try to bring as many issues
up in the process as can be thought of, and then determine
which ones really matter.  ;o)


> 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.

I'd personally prefer the solution to not be specific to OpenGL,
as there might be a host of other files/modules, etc. that one
might want to select between.  I think the 'alternatives'
mechanism present in Red Hat and Debian distributions might be
a better solution, and is also more generic.  I'm not sure if
other distributions use the alternatives mechanism or not, but
hopefully someone can comment about it after reading this.  ;o)

It definitely would be great to see a solution everyone can
agree upon for the future.

Let me know your thoughts about the above.

Thanks Andy,
TTYL