Bug 88264
Summary: | savage driver 24bit depth doesn't work correctly | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thomas M Steenholdt <tmus> |
Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
Status: | CLOSED UPSTREAM | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | ajayr, raf, spam, tor |
Target Milestone: | --- | Keywords: | MoveUpstream |
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
URL: | https://bugs.freedesktop.org/show_bug.cgi?id=3127 | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-05-06 21:53:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Thomas M Steenholdt
2003-04-08 12:16:07 UTC
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 coming up). 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 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. TIA I can reproduce this bug in XFree86 4.4.0 RC2, savage module version 1.1.27 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. TIA you can probably reopen Bug 75 S3 Savage4 Problems in XFree86 4.3 in 24bit depth http://bugs.xfree.org/show_bug.cgi?id=75 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... reported upstream http://bugs.xfree86.org/show_bug.cgi?id=1089 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. 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 the problems 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. Hi. 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: https://bugs.freedesktop.org/show_bug.cgi?id=3127 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" button)? Thanks, Jaime 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: https://bugs.freedesktop.org/show_bug.cgi?id=3127 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. |