Bug 88264 - savage driver 24bit depth doesn't work correctly
Summary: savage driver 24bit depth doesn't work correctly
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL: https://bugs.freedesktop.org/show_bug...
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-08 12:16 UTC by Thomas M Steenholdt
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-06 21:53:20 UTC
Type: ---

Attachments (Terms of Use)
screenshot of desktop (16 Bit depth) (459.05 KB, image/png)
2003-04-08 12:32 UTC, Thomas M Steenholdt
no flags Details
screenshot of desktop (24 Bit depth) (130.60 KB, image/png)
2003-04-08 12:33 UTC, Thomas M Steenholdt
no flags Details
XFree86 log (16 Bit depth - the good one) (33.95 KB, text/plain)
2003-04-08 12:35 UTC, Thomas M Steenholdt
no flags Details
XFree86 log (24 Bit depth - the bad one) (33.20 KB, text/plain)
2003-04-08 12:36 UTC, Thomas M Steenholdt
no flags Details
24 bit resolution 1024x768 w/ digital camera (453.63 KB, image/jpeg)
2004-05-31 19:56 UTC, James Nine
no flags Details

Description Thomas M Steenholdt 2003-04-08 12:16:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
On my IBM ThinkPad T22, using the savage driver at 24 bit depth results in a
strange experience. Although everything works just fine, the color depth is not
24 bit(or at least doesn't look anywhere near it).
Especially the fade of colors on the default background makes it stand out. The
otherwise smooth fade is very "jerky" sort of like a badly compressed .jpg image.

Switching to the vesa driver makes the problem go away and probably more
interesting, going to 16bit makes everything look just fine.

I tried to see if I could compare the strange depth to a sane depth on the vesa
driver, but no! probably more like 8 bit, only the vesa drive dithers at that
depth so i really cant compare it.

I made a few screenshots for you to illustrate the problem, and I'm attaching a
good and a bad X server log file as well!

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

How reproducible:

Steps to Reproduce:
1. Install RHL 9 on a system with a S3 Inc. 86C270-294 Savage/IX-MV (rev 13)
video card
2. Try it at 16 bit depth
3. Try it at 24 bit depth

Actual Results:  16bit is nice and smooth
24bit is not smooth at all

Expected Results:  16bit is nice and smooth
24bit is nicer and smoother

Additional info:

Comment 1 Thomas M Steenholdt 2003-04-08 12:33:00 UTC
Created attachment 91003 [details]
screenshot of desktop (16 Bit depth)

Comment 2 Thomas M Steenholdt 2003-04-08 12:33:41 UTC
Created attachment 91004 [details]
screenshot of desktop (24 Bit depth)

Comment 3 Thomas M Steenholdt 2003-04-08 12:35:44 UTC
Created attachment 91005 [details]
XFree86 log (16 Bit depth - the good one)

Comment 4 Thomas M Steenholdt 2003-04-08 12:36:17 UTC
Created attachment 91006 [details]
XFree86 log (24 Bit depth - the bad one)

Comment 5 Rick Floyd 2003-04-16 07:15:12 UTC
Same thing, with a SuperSavage/IXC 64 (id=8c2e) on a T23. The screenshots don't
do justice to how ugly gradients look in 24 bit mode. I thought that this was
working in 8.0.94 (savage driver 1.1.26), although I can't swear to that w/o
reinstalling it and checking. I can do that if it helps.

The vesa driver isn't stable with this chip in 24 bit mode (X occasionally hangs
coming up).

Comment 6 petrosyan 2003-04-30 16:04:34 UTC
same thing on Savage IX/9 on T20.

24bit depth looks very ugly, had to switch to 16bits

Comment 7 petrosyan 2004-01-13 05:48:11 UTC
this bug is still present in Fedora Core 1 ( XFree86-4.3.0-42 )

Comment 8 Mike A. Harris 2004-01-13 08:26:01 UTC
Thanks for the update.  Changing component to Fedora Core 1.

Comment 9 Mike A. Harris 2004-01-13 08:29:24 UTC
It's possible that the XFree86 CVS savage driver might fix this
problem perhaps.

I don't have Savage hardware or technical specifications however,
so we're more or less restricted to waiting for upstream fixes to
appear.  If I get a chance to try backporting the CVS driver to
4.3.0, I'll update this report, but it'll probably be a while, so
if someone could try it in the mean time, that would be helpful.


Comment 10 petrosyan 2004-01-13 11:06:40 UTC
I can reproduce this bug in XFree86 4.4.0 RC2, savage module version

It is impossible to see this bug in screenshots because they look fine
on a normal computer. they only look ugly on a savage video card that
is using 24 bit color depth.

Comment 11 Mike A. Harris 2004-01-13 11:23:39 UTC
Ok, that's good to know.  It indicates that the current savage driver
still suffers from this bug in CVS, which indicates that it is a stock
bug, and not one introduced by my patches (as previously believed).

I had integrated Tim's newer driver a while back, but did so in a way
that also kept XFree86's changes from his driver, in order to simulate
what the resulting driver would be when XFree86 integrated Tim's new
driver.  It seems that this is exactly what XFree86.org ended up doing
now if the problem is reproduceable there, so I did a good job of
creating the problem before they did.  ;o)

However, it was a mere combinatorial patching, and was not actual
coding, for I have no knowledge of the savage hardware's operation,
nor it's documentation.

Since the problem is present in 4.4.0 RC2, my recommendation, is to
file a bug report in XFree86 bugzilla at http://bugs.xfree86.org and
attach X log and config file to the report.  Hopefully the savage
maintainer or someone else can fix this before 4.4.0 is officially
released, and if so, I can investigate a bugfix backport.

>It is impossible to see this bug in screenshots because they look
>fine on a normal computer. they only look ugly on a savage video
>card that is using 24 bit color depth.

That would be because a screen shot does not capture what is seen
on the display, but rather the contents of video memory.  If the
problem does not appear in a screenshot that is viewed on another
computer, then it is not a problem rendering bits into video memory,
ie: not a data problem.  Rather, it would more likely be a video mode
timing or memory timing problem, or some bandwidth related issue.
That requires in depth knowledge of the hardware's innards to fix
however, so best left to the driver maintainer.

Please post the URL to your upstream bug report once you've filed it,
so I can track upstream progress for possible fixes.


Comment 12 petrosyan 2004-01-13 16:35:34 UTC
you can probably reopen 
Bug 75  	S3 Savage4 Problems in XFree86 4.3 in 24bit depth


Comment 13 Mike A. Harris 2004-01-13 21:14:42 UTC
I would rather if you opened a new report upstream, and then in the
new report, referenced the closed report, as the bug is currently
assigned to me upstream, because at the time, it was not a bug
in XFree86's own driver, but rather in the driver I put together
as a combination of Tim's driver and XFree86's variance from his
code.  I did not expect XFree86 to support a driver that they did
not ship.

However, now the bug is in XFree86 CVS head itself, and so it is
their bug now.  I am not the upstream savage driver maintainer,
and have no intention on investigating the problem as I have no
knowledge of the Savage hardware operation nor specifications
for it, nor access to the hardware, as mentioned above.  So reopening
it is likely to just leave it sit there indefinitely unless it is
reassigned to someone else who works on the driver officially.  But
opening a new report is a much better thing to do in this case IMHO,
as it makes the problem fresh, and thus more likely to be investigated
at all.

Just an opinion however...

Comment 14 petrosyan 2004-01-14 00:04:28 UTC
reported upstream


Comment 15 Mike A. Harris 2004-01-15 09:23:42 UTC
Thanks, I've added myself to the CC on the report there, and will
track this issue, and if a fix becomes available, investigate
a backport.

Comment 16 petrosyan 2004-03-18 04:54:24 UTC
i checked and, as expected, this bug is still present in
xorg-x11- since it comes with 1.1.27 savage
driver. (see comment #10). Alex Deucher mentioned in comment
http://bugs.xfree86.org/show_bug.cgi?id=1089#c1 that it is related LCD
dithering issues. From
http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=333 it looks
like this bug has been fixed in the latest DRI CVS drivers for savage.

Updating the savage driver from DRI CVS would fix this bug, and it
would also enable 3D acceleration for all savage based cards.

Comment 17 Ajay Ramaswamy 2004-05-12 11:14:47 UTC
I have a similar problem, VGA is S3 Savage 4, onboard a IBM NAS 225,
Fedora Core 1 with XFree86 4.30-55 works fine but xorg 0.6.7-2 gives
the problems

Comment 18 James Nine 2004-05-31 19:43:45 UTC
I have an IBM Thinkpad T23, upgraded from Fedora Core 1 final to
Fedora Core 2 final.  I have had a problem with the 24bit depth since
FC1, and moving to FC2, the problem just carried over.  I am using
xorg-x11-xfs-6.7.0-2 and when reading the Xorg log, it says that I'm
using 1.1.27 savage driver.  I have spent the last 2 days researching
this and I have tried Tim Robert's savage_drv.o (1.1.27t for XFree86
4.40RC2) at both 1024x768 & 1400x1050 (both the LCD & display
properties) @ 24bit and this still does not fix it.  Moving down to
16bit depth does not yield this problem.

I have Windows XP SP1 on the same hard drive and when loading that,
the 24bit depth works perfectly under 1024x768.

Comment 19 James Nine 2004-05-31 19:56:44 UTC
Created attachment 100722 [details]
24 bit resolution 1024x768 w/ digital camera

As a screenshot doesn't really do justice, I am attaching a crude digital
camera shot of my LCD screen of what the error looks like.  This is not the
best example, but if you look closely at the circles, you will see the gradient
marks which do not appear on other monitors running the same resolution.  The
vertical & diagonal lines towards the upper left side of the image are not part
of the problem; I think that was created by the camera.

Comment 20 Mike A. Harris 2004-09-29 20:37:26 UTC
http://bugs.xfree.org/show_bug.cgi?id=75 seems to indicate this
bug is fixed now in XFree86 CVS, so should be fixed also in
X.Org CVS as well, as the codebased branched off after that
point in time.

We encourage you to upgrade to the latest version of Fedora Core
(http://fedora.redhat.com), and if this issue turns out to still
be reproduceable in the latest version of Fedora Core, please
file a bug report in the X.Org bugzilla located at
http://bugs.freedesktop.org in the "xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.

Comment 21 Jaime 2005-05-01 18:08:05 UTC

This bug still exists (I've just installed a fresh Fedora Core 4 Test 2 and it's
still there). I've opened another bug in freedesktop.org's bugzilla (as
requested) - here's the link:


I'd like to "re-open" this bug (88264), but the "bug status change" option at
the bottom of this page doesn't have that option - it only says "Leave as closed
- current release".

Should I open another bug in redhat's bugzilla (perhaps using the "Clone as bug"

Thanks, Jaime

Comment 22 Jaime 2005-05-06 02:46:16 UTC
Hi again.

I just want to let you know that this bug has just been fixed (again? :-)), and
this time, it really *is* fixed - please see comments at:


HTH, Jaime (6th May 2005)

Comment 23 Mike A. Harris 2005-05-06 21:51:16 UTC
No need to reopen the bug, I've CC'd myself on the upstream bug report
and am monitoring it.  If X.Org considers the fix to be "stable" without
risk of regression, it should be nominated for 6.8.x stable branch, and
later committed to CVS on the stable branch.  If nobody nominates it for
stable branch, of if anyone objects to it going into stable, then we'll
conclude that it is too experimental for consideration in FC3/FC4 at this
point in time.

Once the patch appears in CVS on the stable branch, we will consider
including it in a future update however.

Comment 24 Mike A. Harris 2005-05-06 21:53:20 UTC
Added to our upstream bug tracker.

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