Bug 102491 - Ability to edit ModulePath via redhat-config-xfree86
Summary: Ability to edit ModulePath via redhat-config-xfree86
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: beta1
Hardware: i386 Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-15 21:48 UTC by Peter Backlund
Modified: 2007-04-18 16:56 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-01 06:12:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
nvidia config util (2.87 KB, text/plain)
2003-10-18 21:09 UTC, Peter Backlund
no flags Details

Description Peter Backlund 2003-08-15 21:48:09 UTC
The ability to edit ModulePath in XF86Config via redhat-config-xfree86 would be
very useful. See discussion in

Both prepend and append would be nice, as well as complete replacement.

Comment 1 Mike A. Harris 2003-08-24 10:02:10 UTC
I agree that this would be nice to have sometime in the future perhaps, but
only once XFree86 driver modules are split out into their own RPM packages,
and come with metadata files which replace the current "Cards" database
mechanism.  This will permit 3rd party vendors such as ATI and Nvidia and others
to include their own metadata files as well.  They will be able to drop
a directory somewhere with the driver files, and drop a metadata file somewhere
as well.  Our config tool should then scan for the metadata files to determine
what all drivers are installed in the system, and where, and then provide
a method for the user to select the particular driver they want, with
preference being for the Red Hat supplied driver (if one exists for the
device).  If a non Red Hat driver is chosen, the config tool should then
use ModulePath in the config file to override the default location the
X server looks for modules.

In order to implement all of this will require a lot of careful and well thought
out planning.  Before the config tool gets modified for this, work needs
to be done to make the XFree86 SDK work and work on all architectures, then
split the video driver modules into individual RPM packages, then finalize
my new metadata file format for video drivers and implement the client
library which will access the files.  Then I need to create new metadata
files for all of the video drivers we ship, and include them in each
driver module subpackage.  This is kindof the equivalent of a Windows .INF
file in some ways.

Once I've completed this and tested the client library, then our config
tools can be modified to include support for the new metadata format, and
vendors such as ATI/Nvidia can begin using the new metadata files for
describing their video driver's compatibility and configuration.

This work is currently something I'm doing in my spare time, and I'm not
sure when it will be done, so there's no ETA yet for it.

That said, it might be simple to create a commandline tool which uses
libxf86config to read/write the config file, and allow
addition/modification/removal of of ModulePath in that manner.  Not something
I'd be working on anytime soon personally, but if someone else decides
to write a utility like that, I'd be glad to test it and perhaps include
it with XFree86.

Comment 2 Peter Backlund 2003-10-18 21:09:40 UTC
Created attachment 95286 [details]
nvidia config util

Comment 3 Peter Backlund 2003-10-18 21:10:04 UTC
I've created a small, dedicated-to-nvidia python script with the Fedora
packaging of the Nvidia driver. Attaching it here for initial review. If there's
interest, I could try transforming it into a patch against r-c-xf86.


Comment 4 Peter Backlund 2004-09-23 15:44:19 UTC
Noticed some activity here...

The attached config script is now in use in livna.org's nvidia and ati
graphics driver packages, and works really well.

Most recent version:


Comment 5 Mike A. Harris 2004-10-01 06:12:19 UTC
Deferring for review in Fedora Core 4 development timeframe.

Comment 6 Mike A. Harris 2005-04-20 15:14:57 UTC
I think the best long term solution, is to have the X server have
a few predefined directories to look in to handle the common case,
and to standardize driver installation upon that.  We want to move
more and more towards the X server autodetecting as much things
as possible, and not needing configuration.  While there will always
be a need for certain configuration, when considering new functionality,
I think we should be thinking for the long term and making upstream
enhancements to Xorg that make configuration as unnecessary as

We'll be looking into these type of things in the FC5/FC6 timeframe.

Note You need to log in before you can comment on or make changes to this bug.