Perhaps upstream, perhaps xf86-video-sunffb related: With referenced (masked) server, xf86-video-sunffb-1.1.0, etc., and a local rgb database, the Xorg.0.log file claims: /var/log/Xorg.0.log:(**) RgbPath set to "/usr/share/X11/rgb-local" which is correct. Indeed, if I look for showrgb | grep fuchsia/dim, it tells me 126 0 71 fuchsia/dim which is also correct. But when I try to 'emacs -bg fuchsia/dim', say, I get Undefined color: "fuchsia/dim" I have no idea where the change comes from, nor if it is intentional or not. But whatever it is, it is most unwelcome.
Why is that correct? It looks like you have an incorrect setting. /var/log/Xorg.0.log:(==) RgbPath set to "/usr/share/X11/rgb"
(In reply to comment #1) > Why is that correct? It looks like you have an incorrect setting. > > /var/log/Xorg.0.log:(==) RgbPath set to "/usr/share/X11/rgb" > Well, because: 1. I have RgbPath "/usr/share/X11/rgb-local" 2. My Xorg.0.log claims: (**) RgbPath set to "/usr/share/X11/rgb-local" 3. Just for fun, before filing this I'd forced /usr/share/X11/rgb.txt and /usr/share/X11/rgb-local.txt to be identical, and they both know about fuchsia 4. Only change needed to trigger this is is upgrade of server and drivers; my rgb-local.txt file has not changed for years, and xorg.conf did not change with the upgrade. 5. If, say, I run 'emacs -bg fuchsia -display <some-system-with-unmasked-server>:0.0' I get what I expect. So only variable in the mix is the server/driver upgrade. xorg.conf, etc. are as always.
Oh, yes, there is this ChangeLog entry, too: Replace rgb text file loading with static rgb color table. That suggests that rgb is no longer an RDEPEND for xorg-server, but rather just ignored, and that once the server is built, the user can no longer change the rgb database. At a minimum, there needs to be w way for the user to specify what rgb database should be used; if I find it useful to change rgb databases, I suspect others do, too (since X11 has supported it from day 0 --- yesterday). I'm checking to see if building the server with every conceivable rgb database on the system is identical to my local one makes a difference, but it looks to me as if it's forced in os/oscolor.c ; os/oscolor.h to ignore any local rgb database. (i.e., a hard coded option in oscolor.c to disallow user override.) How removing this capability is a good thing escapes me completely, but is a show stopper so far as I am concerned. I rely heavily on what is in my own rgb-local.txt definitions.
Cross reference upstream at https://bugs.freedesktop.org/show_bug.cgi?id=6608 If a Gentoo fix is required, it's trivial at this point.
Great, we'll track it there.
