Red Hat Bugzilla – Bug 65310
XFree86-4.2 8-bit colormap failure
Last modified: 2007-04-18 12:42:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
Description of problem:
XFree86-4.2 does not function properly when started in 8 bit color depth. Almost
all clients are unable to allocate colors.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Set /etc/X11/XF86Config-4 to start with DefaultDepth 8
3.Start XWindows with fvwm2 as default window manager.
4.Notice the goodstuff client was unable to allocate correct colors.
5.Try, 'xterm -fg white -bg darkslategrey'
Actual Results: The clients were unable to allocate colors other than basic
black and white. The xterm command displays white on white because the
background color could not be allocated.
Expected Results: A colormap should be allocated by the Xserver. All version of
XFree prior to 4.2 do not have this problem. The problem does not appear to have
any relation to the Xdriver being used. Problem has been noted with the
following Xdrivers 'mga,ati,radeon,nv'
This is most likely due to the Render extension. I'm not sure if I'd
consider it a bug or not. I must be honest in saying that 8 bit depth
is basically obsolete, and as such debugging or troubleshooting such
problems is very low priority.
Most modern video hardware support overlays which allow an 8 bit depth
overlay window while running in 16 or 24 bit depth. I suggest running
your pseudocolor apps using the overlay support of your video hardware.
In either case, you'll likely find the XFree86 mailing lists as a
speedier resolution to this problem.
I've spotted this problem too. My hardware may be obsolete (HP Omnibook 800)
but it still works and I'd like to be able to run X on it without the server
stealing all but 12 of the colours.
There are a couple of recent threads about this on the Xpert mailing list.
The bottom line is that the problem is with the RENDER extension and that it's
fixed in CVS.
Indeed, this is fixed in CVS. Backporting the fix at this time is not
feasible however. The solution for this will appear in a future release
of Red Hat Linux once XFree86 4.3.0 is released.
I'm closing this as DEFERED to come back to when 4.3.0 is out.
Fixed in XFree86 4.3.0 in RHL 9