Bug 173036 - rgb.txt should be in an architecture-independent location
Summary: rgb.txt should be in an architecture-independent location
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server-utils
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
Blocks: xorg-modular
TreeView+ depends on / blocked
Reported: 2005-11-12 19:56 UTC by Jeremy Katz
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2005-11-23 16:21:51 UTC

Attachments (Terms of Use)

Description Jeremy Katz 2005-11-12 19:56:25 UTC
/usr/lib/X11/rgb.txt should probably be /usr/share/X11/rgb.txt


Comment 1 Nalin Dahyabhai 2005-11-16 23:47:31 UTC
Moving this file (even from its previous location, /usr/X11R6/lib/X11/rgb.txt)
broke/breaks/will break old configuration files which specified this as the
value for the RgbPath setting, causing older applications to draw black pixels
where colored-by-name pixels were intended.

Comment 2 Michal Jaegermann 2005-11-17 01:17:31 UTC
After an update to "modular X" /usr/X11R6/lib/X11/rgb.txt is simply gone.
To make things more interesting on x86_64 this file resides in
/usr/lib64/X11/rgb.txt.  There is no /usr/lib/X11 at all.  At least a link
for an old location would be nice. 'xdvi', for example, does not start properly 
without this file.  Even when  /usr/X11R6/lib/X11/rgb.txt is present there are
complaints but at least menus do show up.

Comment 3 Mike A. Harris 2005-11-17 04:20:10 UTC
This is an unintended bug, caused due to upstream X being in a bit of
flux.  There are 4 problems that we need to solve in a future update:

1) The rgb.txt file should be in /usr/share/X11/rgb.txt as it is arch
   independent data.

2) Everything that is part of X11R7 that reads this file directly, needs
   to be updated to find it in the new "correct" location.

3) The Xorg server package needs to be updated to remove RgbPath from the
   config file, as it should not be necessary to specify this.  The X
   server should use it's built in default, and nobody should ever move
   this file anyway.  Why it is even configurable is somewhat of a

4) The config tools need to be updated to not write out RgbPath or

Please file separate bugs against the config tools for #4.

Comment 4 Jeremy Katz 2005-11-17 04:34:20 UTC
No need to file a bug for 4 -- we've never written out ModulePath and I changed
things so that RgbPath shouldn't get written out as of a few days ago

Comment 6 Mike A. Harris 2005-11-17 06:08:41 UTC
(In reply to comment #4)
> No need to file a bug for 4 -- we've never written out ModulePath and I changed
> things so that RgbPath shouldn't get written out as of a few days ago

Ok.  I'm still going to have the upgrade scripts update ModulePath if it
is present and contains the old X module path, as I know some 3rd party
driver installs change the path, and put the X path last.  That should
keep them happy.

Comment 7 Mike A. Harris 2005-11-17 07:00:58 UTC
*** Bug 173435 has been marked as a duplicate of this bug. ***

Comment 8 Mike A. Harris 2005-11-17 12:26:01 UTC
To everyone experiencing this:

Edit your xorg.conf file, and remove the line that has:

    RgbPath ...

Then restart the X server.  Does this make the problem go away?  If so,
then I can have a real quick fix for this problem for everyone by having
the upgrade of the X server, remove RgbPath from xorg.conf, as it should
never have been put in there by our crazy config tools anyway. ;o)

Then the actual location of rgb.txt becomes transparent to the system
hopefully, and I can lower the priority of fixing it by a week or so,
and divert my resources to other more critical problems that have come
up, and either pick up a fix from RC3, or fix it in a few weeks.

Comment 9 Mike A. Harris 2005-11-17 16:08:47 UTC
The new xorg-x11-server-0.99.3-6 package contains a fix for the xorg.conf
RgbPath problem.  Please test it, and see if the failing applications work
now.  That does not resolve this bug, however it should make the problem
people are experiencing due to this go away hopefully.

Comment 10 Nalin Dahyabhai 2005-11-18 00:39:57 UTC
0.99.3-6 corrects the problem on my system.

Comment 11 Willem Riede 2005-11-19 19:20:27 UTC
rgb.txt is part of xorg-x11-server-utils which is still at 0.99.2-3 ?

on my x64_86 it lives in /usr/lib/64/X11, but xorg looks in /usr/lib/X11 for it.

even after I set RgbPath in xorg.conf to be "/usr/lib64/X11", something is still
not right - from Xorg.0.log:

(**) RgbPath set to "/usr/lib64/X11"
(==) ModulePath set to "/usr/lib64/xorg/modules"
Couldn't open RGB_DB '/usr/lib64/X11'

Comment 12 Michal Jaegermann 2005-11-19 20:45:52 UTC
> even after I set RgbPath in xorg.conf to be "/usr/lib64/X11"

I think that "/usr/lib64/X11/rgb" would be really expected but I am not sure.

Comment 13 Mike A. Harris 2005-11-20 04:40:11 UTC
Just to avoid confusion, there are multiple problems going on here.  Let me
try to cover them all and give status on each, to avoid everyone from having
to guess about things..  ;o)

1) The upstream tarballs install rgb.txt into %{libdir}/X11 which is
   /usr/lib/X11 on 32bit systems, and /usr/lib64/X11 on 64bit multilib
   systems.  This is bad, as this is an architecture independent data
   file, which should be shared.  It belongs in %{_datadir}, not

Solution: In the latest xorg-x11-server-utils package in Fedora CVS, the
whole package is updated to install the data files from all of the apps
it ships, into %{_datadir} where they belong, including rgb.txt.

2) The X config tools in Fedora Core 4, and all earlier releases of FC,
   RHEL, and RHL all put the line RgbPath into the config file, even though
   there is _no_ reason to specify this information in the config file, as
   it is a built in default.  Our config tools seem to have a knack for
   over-specifying defaults in the config file, which eventually change,
   and the config file no longer points at the right location.

Solution: The latest xorg-x11-server package, contains an rpm %post script
now, which will remove the RgbPath directive from the xorg.conf if it exists.
It also will check for ModulePath directive(s), and if present, it will
search and replace the primary X server module directory with the new one,
and leave any other ModulePath's alone.

3) The X server, and any other software that directly accesses the rgb.txt
   file, need to know exactly where it is located, either via built in
   compile-time defaults, or via configuration files or commandline options.
   The only sane default operation of course, is for rgb.txt to be found
   where expected without any config file options or overrides.

Solution: Now that the problem #2 is solved above, we remove that from
the equasion.  Now that problem #1 is solved, we will find out wether the
X server needs to be patched and recompiled to find rgb.txt properly or
not.  In order to have this properly tested, both of the solutions for
#1 and #2 must be built and installed first, or one of those 2 problems
will hit people.  Beehive is not being cooperative with me, so that might
take a while.

Once we've got things properly built in beehive, we can test wether the
rgb.txt file is being found properly or not, and if not, we can start
investigating the X server source/configure options for why.

Apologies for any inconveniences, but I hope this helps to understand
where things are at now.  I'll update when I have more news.

Thanks for testing!

Comment 14 Mike A. Harris 2005-11-23 16:21:51 UTC
I finally waded through the xorg-horror-story bug alias filesystem symlink/dir
issue, and climbed the "fix it" dependency chain to allow the new package
to be built in beehive for this bug.

xorg-server-utils-0.99.2-5 fixes this problem.

Comment 15 Michal Jaegermann 2005-11-25 05:51:54 UTC
> xorg-server-utils-0.99.2-5 fixes this problem.

I am ultimately lost which problem is "this".  It is true that
xorg-x11-server-utils-0.99.2-5 package provides /usr/share/X11/rgb.txt;
but when I am starting X server from xorg-x11-server-Xorg-0.99.3-7 without
adding an explicit RgbPath in xorg.conf then I see in logs:

(==) RgbPath set to "/usr/lib/X11/rgb"
(==) ModulePath set to "/usr/lib64/xorg/modules"
Couldn't open RGB_DB '/usr/lib/X11/rgb'

and, of course, there are colour troubles.

Is this is another issue or this bug should be reopened?

Comment 16 Mogens Kjaer 2005-11-25 13:36:44 UTC
To "fix" this problem in FC5test1, add:

 RgbPath "/usr/share/X11/rgb"

to the Files section of xorg.conf

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