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): RH-7.3 XFree86-4.2 How reproducible: Always Steps to Reproduce: 1.Set /etc/X11/XF86Config-4 to start with DefaultDepth 8 2.Install fvwm2 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' Additional info:
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. http://www.xfree86.org/pipermail/xpert/2002-May/thread.html 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