Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 65310 - XFree86-4.2 8-bit colormap failure
XFree86-4.2 8-bit colormap failure
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-05-21 15:45 EDT by Rob Wallace
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version: 4.3.0-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-25 05:56:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rob Wallace 2002-05-21 15:45:05 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):
RH-7.3 XFree86-4.2

How reproducible:

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:
Comment 1 Mike A. Harris 2002-05-22 14:24:09 EDT
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.
Comment 2 Ron Yorston 2002-05-25 14:48:27 EDT
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.
Comment 3 Mike A. Harris 2002-07-26 07:54:05 EDT
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.
Comment 4 Mike A. Harris 2003-04-25 05:56:18 EDT
Fixed in XFree86 4.3.0 in RHL 9

Note You need to log in before you can comment on or make changes to this bug.