Description of problem: Rawhide (Fedora 9.92)'s "radeon" driver introduced one or more drawing behaviors different from standard practice (i.e. other video drivers and virtual drivers in vmware and virtualbox, and the "radeon" driver in F9), causing at least two cases of misdrawings on my system. Since the symptoms are definitely not limited to these 2 cases, fixing the driver itself should be the ultimate solution. Case 1: A "Radeon 9200" video card will draw the active menu in Fedora 10 Snapshot 3's default Nodoka theme badly (as in this screenshot: http://i34.tinypic.com/212ziuf.png). The correct drawing should be http://wwoods.fedorapeople.org/screenshots/f10-nodoka.png (notice the background color of the active main menu "File"). I filed a bug against this particular case under "gtk-nodoka-engine" and the bug's assignee has successfully found a workaround on his side (i.e. the Nodoka engine) to fix the misdrawing. In that bug report he also described which particular drawing function call (i.e. "clip region") is causing the misdrawing. However, I also found another misdrawing case (see Case 2 below) which is no longer limited in the realm of Nodoka and can't be solved by him alone and need radeon driver developers' to fix the implementation of drawing functions such as "clip region" in the radeon driver. Case 2: Compare these two screenshots: (1) Firefox in Fedora 10 Snapshot 3 Live CD running in VirtualBox: http://i37.tinypic.com/a47erc.png (2) Firefox in Fedora 10 Snapshot 3 running in a real computer with Radeon: http://i36.tinypic.com/4h88xh.png Note the difference is the Address box and the Search box have different background colors. What's more, any text entered in these boxes in the Radeon case will have white background (and the rest of the text box is still in light gray. And, if I right click such a text box to bring up the right-click menu and then click elsewhere to cancel the menu, the region in the text box previously beneath the menu will become white. So the problem is the text boxes should be white initially. Obviously Case 2 can be caused by the same misbehavior of the readeon driver's implementation of the "clip region" function (i.e. the function resets parameters like "gradient" after being called), among other possible function misbehaviors. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.9.0-38.fc10.i386 How reproducible: See above. Expected results: See above. Additional info:
The bug report against "gtk-nodoka-engine" is at https://bugzilla.redhat.com/show_bug.cgi?id=469398 . It contains details on how to reproduce a misdrawing with the radeon driver (especially in Comment #11), which would be useful for you to find a fix on the radeon driver side.
Note that these problems don't exist at all in Fedora 9's radeon driver. So an easy solution is to revert the radeon driver to its F9 version.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 322312 [details] F10 Snapshot3 Live CD's Xorg.0.log
Created attachment 322313 [details] F9's xorg.conf
Hi Matej Cepl: Before seeing your comment I have just freshly installed F9 over my F10 partition. However, I still have a F10 Snapshot3 Live CD at hand so I use it first. The F10 Live CD does not have a /etc/X11/xorg.conf, but it has a /var/log/Xorg.0.log which I have attached to this bug report, named "F10 Snapshot3 Live CD's Xorg.0.log". You can see in this log F10 indeed loads the "radeon" driver. Regarding xorg.conf, I can assure you that my F10's xorg.conf did specify "radeon" as video driver, i.e. I saw this line in it: Driver "radeon" Also, my (now gone) F10 is an upgrade from a freshly installed F9, and its xorg.conf didn't seem to differ from the xorg.conf of my currently running F9. So I also attached my current F9's xorg.conf ("F9's xorg.conf") if you're interested. If you still need a F10 installation's xorg.conf please let me know, and I will temporarily install the F10 Live OS to my hard disk. But I hope I don't have to because I hate this bug...
In F10 Live OS, the symptoms also exist. Also, in my (now gone) F10, if I select "ati" as video driver and restart GNOME, the symptoms also exist.
Same here, I see rendering glitches with my Radeon Mobility M9+. They go away if I force XAA acceleration instead of EXA. (This is with xorg-x11-drv-ati-6.9.0-54.fc10.i386.)
Created attachment 324688 [details] My Ubuntu 8.10 Xorg.0.log
Created attachment 324689 [details] My Ubuntu 8.10 xorg.conf
In Ubuntu 8.10 there isn't such a bug. I have attached Xorg.0.log and xorg.conf from Ubuntu 8.10.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Re comment #12: Odd, I've seen it in Ubuntu 8.10. Again, in that case it goes away when you switch to XAA.
okay I think I've fixed this. please try xorg-x11-drv-ati-6.9.0-59.fc10 from koji, or when I push it into updates.
Currently I've settled down in Ubuntu and I may try a Live OS when F11 is out...
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.
Isn't it a bit hasty to close this as INSUFFICIENT_DATA just under 8 hours after a proposed fix was pushed to Koji, when I and many others will not have had the opportunity to try it out? Please re-open.
Well, yeah, I missed that you are here as well -- when reporter of the bug says switches to Ubuntu, it usually means the end of the bug for me. Sorry. Reopening. Does the koji package helped?
Created attachment 324910 [details] Xorg.0.log from session using new driver
OK, the main issue appears to be fixed in the driver from Koji. (When I first logged in, I noticed some corrupted pixels on a few of the frames of the spinning pointer, but it went away --- I'll keep an eye on it.) I've attached the Xorg.0.log above.
xorg-x11-drv-ati-6.9.0-59.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/xorg-x11-drv-ati-6.9.0-59.fc10
xorg-x11-drv-ati-6.9.0-61.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.