Description of problem: GNOME applications show corrupted bitmap font rendering when XAA acceleration is enabled on an ATI X800. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.7.195-5.fc9. How reproducible: Always. Steps to Reproduce: 1. Login to GNOME session. 2. Open GNOME terminal. 3. Set terminal font to Lucida Typewriter. Actual results: Text rendering is badly broken. Expected results: Text is rendered in a readable form. Additional info: - This only affects GNOME applications [not plain X ones] like GNOME terminal or gedit. Is this a cairo issue? - Enabling EXA acceleration mode restores correct font rendering. - Selecting corrupted text fragments or moving a window across the terminal window makes the text [partially/temporarily] reappear. - I'm not sure if the issue is specific to the ATI driver or a general XAA/EXA problem.
Created attachment 289401 [details] Sample screenshot of GNOME terminal using LuciaTypewriter font
Created attachment 289511 [details] xorg.conf created by anaconda
Created attachment 289521 [details] Xorg.0.log for xorg.conf created by anaconda
*** This bug has been marked as a duplicate of 417241 ***
(In reply to comment #4) > > *** This bug has been marked as a duplicate of 417241 *** I disagree: bug 417241 describes a very different issue. In my case, only bitmap fonts are concerned whereas over there, it appears to be a general problem. Moreover, no reference is made to whether the issue is related to the acceleration architecture which is crucial for the current bug since setting "accelmethod" to "exa" settles the issue [without being a proper solution though].
Whereas bug 417241 seems to have been solved by updating to driver version xorg-x11-drv-ati-6.7.196-3.fc9, no progress here ..
In case it's useful, I'm seeing this on my RV370 (Radeon X550) with xorg-x11-drv-ati-6.7.196-5.fc9 (also on x86_64), and setting "AccelMethod" "EXA" likewise makes the problem go away.
I'm seeing this too, and for me setting "AccelMethod" "EXA" fixes things too. I have an radeon 9800 XT on a fully up2date x86_64 rawhide. Downgrading to F-8 xserver and ati driver fixes things for me. I've some limited experience with video debugging and good C-coding skills and I would really like to see this fixed (EXA == slow on r300) please let me know what I can do to help.
Interestingly, I switched to EXA, and it works fast on my r300! I was really surprised. The one thing that is required is DRM working correctly. Without radeon.ko loaded, it was really slow. Plus, I have PCIe (as opposed to AGP), so that might make a difference (because of much faster card-to-RAM transfer).
Okay, After reading the related (duplicate?) bug 384631, which refers to: https://bugs.freedesktop.org/show_bug.cgi?id=13224 Where the same problem is seen with intel graphics (which I've seen in the beginning of F-9 too) I've decided to blame the X-server and I've downgraded my xserver + xserver-sdk to the ones from F-8 updates and then rebuild the F-9 xorg-x11-drv-ati from CVS, and that works fine, so most likely not the ati driver but the Xserver is to blame. Note BTW that here: https://bugs.freedesktop.org/show_bug.cgi?id=13224 Bill Nottingham says this is fixed for intel graphics with an intel driver update, maybe the latest intel driver has switched to exa?
BTW this is pretty bad (also corrupts fixed width fonts in firefox, making several websites including bugzilla unusable) so I'm adding this to the F-9 X blocker.
I think fp.o bug 13104 is the one of interest to us. It also has some hints about where the problem really lays. And it totally deserves to block F9.
*** This bug has been marked as a duplicate of 384631 ***