Bug 65740 - (Possibly RENDER) Bad colormap when choosing 8 bit resolutions...
Summary: (Possibly RENDER) Bad colormap when choosing 8 bit resolutions...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86-Servers   
(Show other bugs)
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-31 00:14 UTC by Richard Munroe
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-21 11:52:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Richard Munroe 2002-05-31 00:14:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
This did NOT happen with either 7.1 or 7.2 redhat releases.  When configuring
any 8 bit mode with my monitors (I've tried a Sony Multiscan 17sf1 and a
Viewsonic P810 with the same results) the first three colors of the colormap get
turned into a deep blue.  If I switch to any 16 bit mode the colors come out Ok.
 This problem is 100% reproducible and happens with either an upgrade from 7.2
to 7.3 or with a new install of 7.3.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Run Xconfigurator
2.Select a monitor (either Sony Multiscan 17sf2 or Viewsonic P810)
The video card is a vanilla S3.
3.Select any 8 bit display mode.
4.Test the selected mode.

Actual Results:  The X configuration test never completes and the machine has to
be rebooted.  The X configuration files in /etc/X11 ARE rewritten.  The color on
the display is shifted well to the blue end of the color spectrum rather than
the standard initial gray pattern.  The configuration never completes.

Expected Results:  The X configuration test screen should show up for acceptance.

Additional info:

Comment 1 Mike A. Harris 2002-05-31 06:11:12 UTC
I've got a couple ideas as to what the problem could be, but first I'd like
to say something because you seem (understandably) a bit frustrated.

While it may have worked before, and doesn't seem to now, this is not at all
necessarily a "Red Hat bug".  XFree86 is maintained upstream by XFree86.org,
and bugs happen.  We simply do not have every piece of video hardware, and
every computer possible to test all of the possible combinations out there,
nor the manpower to do so if we did have all the hardware.  As such, we ONLY
test the most commonly used hardware that we have access to, and we rely on
our private beta team, and our own users and customers to test and report
bugs to us during our beta test periods.

Unfortunately, a lot of people don't take the time to test out a lot of
stuff, and we end up getting bug reports like this one, or rather old
hardware.  People expect if it worked before, it should still work, and
if it doesn't, it is our fault.  While that seems reasonable, the deck
of cards is not in our hands, it is in the hands of XFree86.org, and of
our testing community.  As such, many bugs are found after the fact, once
a new release is out, and users hammer on it much harder than during any
beta testing.  This is unfortunate, but there isn't much I can do about
it other than try to find solutions as problems are reported.

That said...

It is possible that the problem you're having, is due to the RENDER
extension.  8bit depth is very rarely used nowadays, and gets very little
testing by anyone.  In the current 4.2.0 release, the RENDER extension
is very colormap hungry, and leaves few colormap entries left for other
apps to use.  This results in 8bit depth being somewhat unuseable.  This
problem was not discovered or reported during all of the upstream XFree86.org
beta testing, or final release, nor in our testing or users testing.  Fact
is, barely anyone uses 8bit depth.  About the only people who use it still
do so because they have to in order to use some obscure legacy app that
only works in 8bit.  I'm assuming that this is the case for you, and that
the RENDER issue is the problem you're having.  If so, it will be fixed
in XFree86 4.3.0, which is due out near the end of the year.  I'm planning
on looking into a backport of the fixes if it is possible.

It is also possible that the problem isn't related to RENDER.  If not, then
it would almost certainly have to be a video driver issue I would presume.
If this is the case, "vanilla S3 card" doesn't mean much at all.  S3 makes
tonnes of video cards, and they are not all alike.  I would need to know
the exact specific model of the card, including its PCI ID, as well as
a copy of your XFree86 log file, and your config file in order to diagnose
the problem.  You can attach them using the link below.

Possible workarounds which may or may not be appropriate for the time being:

1) Dont use 8bit depth
2) Use 24bit depth + 8bit overlay if psuedocolor is required
3) Try a different video card
4) Try compiling XFree86 from CVS, or at least the S3 driver from CVS

I don't have any S3 hardware in order to attempt to reproduce, but I
can try using other hardware to see if the RENDER issue results in the
same thing.

I also recommend that you report this problem directly to xpert@xfree86.org
so that more than one person is working on the issue, and can comment on it.

I'll update the report when I've had a chance to investigate the new
RENDER code.

Comment 2 Mike A. Harris 2002-09-05 19:35:30 UTC
Defering issue for XFree86 4.3.0 testing phase.

Comment 3 Mike A. Harris 2003-02-21 11:52:28 UTC
4.2.99.x in rawhide, and our current beta releases should resolve this
problem in 8bit depths.

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