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.)
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
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!
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
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.
Three years later this still isn't getting reverted.
I insist this be corrected.
(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."
(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.
(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
Then he can give them. Valid technical arguments are given much more weight
than "I insist you write the code I want." without explanation.
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.