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):
Steps to Reproduce:
1. Install RHL 9 on a system with a S3 Inc. 86C270-294 Savage/IX-MV (rev 13)
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
Created attachment 91003 [details]
screenshot of desktop (16 Bit depth)
Created attachment 91004 [details]
screenshot of desktop (24 Bit depth)
Created attachment 91005 [details]
XFree86 log (16 Bit depth - the good one)
Created attachment 91006 [details]
XFree86 log (24 Bit depth - the bad one)
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
same thing on Savage IX/9 on T20.
24bit depth looks very ugly, had to switch to 16bits
this bug is still present in Fedora Core 1 ( XFree86-4.3.0-42 )
Thanks for the update. Changing component to Fedora Core 1.
It's possible that the XFree86 CVS savage driver might fix this
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.
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.
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.
you can probably reopen
Bug 75 S3 Savage4 Problems in XFree86 4.3 in 24bit depth
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
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
Just an opinion however...
Thanks, I've added myself to the CC on the report there, and will
track this issue, and if a fix becomes available, investigate
i checked and, as expected, this bug is still present in
xorg-x11-0.0.6.6-0.0.2004_03_11.5 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.
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
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.
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.
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.
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"
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)
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.
Added to our upstream bug tracker.