Bug 6608 - Disabling user selectable rgb database in xorg-server-1.0.99.901 is very bad news for those of us with our own rgb databases
Disabling user selectable rgb database in xorg-server-1.0.99.901 is very bad ...
Status: RESOLVED WONTFIX
Product: xorg
Classification: Unclassified
Component: Build/Modular
git
All Linux (All)
: high major
Assigned To: Xorg Project Team
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-16 01:03 UTC by Ferris McCormick
Modified: 2010-08-25 12:40 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ferris McCormick 2006-04-16 01:03:04 UTC
Current release candidate for 7.1 unconditionally disables the facility for
specifying an rgb database file in xorg.conf (although the entry is still
recognized and log claims it is used).  For anyone like me who has a custom
rgb-local.txt rgb database, this is a serious limitation:  I can (1) build the
xerver by hand to revert to expected behavior; (2) try to find everywhere over
the years I have built my own color scheme into things; (3) not bother with any
 further xorg-7.xx testing or upgrades.

Please make (keep, I think) this a configure option.  (Consider the poor user
who might prefer to specify '-bg jaune' or '-bg gelb'. :) )

(High priority because the "fix" is completely trivial (one character), but the
impact for me is severe.)

Compare: https://bugs.gentoo.org/show_bug.cgi?id=130003
Comment 1 Daniel Stone 2007-02-27 01:31:32 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 2 Thomas Schweikle 2007-04-18 23:49:12 UTC
Could confirm this bug. Any "RGBPath" in "/etc/X11/xorg.conf" is ignored and only the default, build in rgb-database is used. The logs claim to use a given, configured rgb-database, but while starting X this is only logged. The database itself is never accessed. In fact it is reported to be used even if it does not exist!
Comment 3 Ferris McCormick 2007-04-19 04:13:30 UTC
Yes, there is a define (in os/oscolor.c) which forces use of the built-in RGB database, even though oscolor.c knows perfectly well how to read the one provided by the rgb package:  At oscolor.54, we have this:

#define USE_RGB_BUILTIN 1

#if USE_RGB_BUILTIN

I have never seen the point of this because it reduces functionality (some of use custom rgb databases) and is easily defeated just by changing that "1" to a "0", which I do every time I have to rebuild xorg-server.  Now, that gets old after the first 20 or 30 times (I have to build it on several systems).

I don't object to having the option to use the built-in database, but I really think it should be controlled by a configuration option --- instead of defining USE_RGB_BUILTIN in oscolor.c, let the configure script define it like it defines other things.
Comment 4 ajax at nwnk dot net 2010-08-09 12:47:58 UTC
Three years later this still isn't getting reverted.
Comment 5 Jonathan Kollasch 2010-08-24 14:14:27 UTC
I insist this be corrected.
Comment 6 Alan Coopersmith 2010-08-24 14:25:06 UTC
(In reply to comment #5)
> I insist this be corrected.

We'll need a lot better reason than "Someone we've never heard of insisted."
Comment 7 Marc Balmer 2010-08-24 23:56:44 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I insist this be corrected.
> 
> We'll need a lot better reason than "Someone we've never heard of insisted."

Alan, I find that you are missing a bit the tone with your reply, not to say it could be perceived as being arrogant.  Jonathan Kollasch is a respected NetBSD developer, at he is not someone noone has ever heard of...  I have worked with him, I am sure Matthieu Herrb has had contact with him, too.

I am sure that Jonathan has very valid reasons to request the change being reverted, and for now I don't see really we it should not be done?  But then I am not an expert in the RGB area.
Comment 8 Alan Coopersmith 2010-08-25 07:58:07 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > I insist this be corrected.
> > 
> > We'll need a lot better reason than "Someone we've never heard of insisted."
> 
> Alan, I find that you are missing a bit the tone with your reply, not to say it
> could be perceived as being arrogant.  Jonathan Kollasch is a respected NetBSD
> developer, at he is not someone noone has ever heard of...  I have worked with
> him, I am sure Matthieu Herrb has had contact with him, too.

I'm sorry - not being active in NetBSD, I've never heard of him, and I found 
the tone of "I insist this be corrected" with no explanation to be quite 
offputting - as an open source developer, I'm sure he's used to users demanding 
their bugs be fixed without offering any help, and understands our frustration
with demands like this.

> I am sure that Jonathan has very valid reasons to request the change being
> reverted, 

Then he can give them.   Valid technical arguments are given much more weight
than "I insist you write the code I want." without explanation.
Comment 9 James Cloos 2010-08-25 12:40:22 UTC
Xcms.txt is still supported; it is not difficult to convert a file from
rgb.txt syntax to Xcms.txt syntax.  Plus, you can do a better job with
Xcms.txt than rgb.txt could ever do, since it is colour-space-aware.