Description of problem: With my Z60m laptop and Mobility X600 video chipset I see graphical corruption in Fedora 9 that wasn't present on Fedora 8 with the same system. Temporary graphical corruption, windows and other graphical elements are overdrawn with vertical black lines sometimes when moved, the lines remain when things are idle again but covering and then revealing the area to force a redraw fixes the corruption. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.8.0-14.fc9.i386 How reproducible: Happens occasionally in normal use, but not to the extent as to make the system unusable. Can be reproduced at will by specific examples... Steps to Reproduce: 1. Create an xterm on an otherwise "empty" desktop (Nautilus running) 2. Drag e.g. the Nautilus "Computer" icon around near the edges of the xterm. Actual results: The icon is steadily overdrawn with black lines. When you release the drag Nautilus will redraw the icon in its new position, eliminating the corruption. Expected results: Icon should not be overdrawn Additional info: I'd guess this might be a timing or synchronisation problem, with the xterm drawing somehow drawing onto the icon, rather than being clipped to avoid it or something like that. Hopefully an X guru can figure this out, or can ask me to perform some further relevant experiment that will diagnose the problem. As a pre-emptive step, let me say that I don't have an X.org configuration file, the configuration is whatever the driver does by default on my hardware. I am using a laptop with an LCD panel, and I haven't tried this with an external display, but I could (with some notice to go get one) if it might help. Oh, and the PCI ID of the chip, in case the description in the Summary gets lost, or is insufficient to determine the exact hardware, is 1002:3150
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 log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 306981 [details] Xorg log file on affected system This is a log from a freshly started machine. I logged in, checked that the bug still occurs and then copied this log. I don't see any smoking gun in the log, but at least it should help to rule out some things.
With some further experimentation, the reproducible element above is restricted to the scenario where the xterm has a scrollbar enabled. The xterm scrollbar has a sharp black line at the edge closest to the text, and it seems that this line is what's being drawn over other items. With scrollbars temporarily disabled (control middle-click, top item in menu) this specific corruption is no longer reproducible. This shouldn't be caused by xterm itself, at least it's never shown any previous intention to draw on windows belonging to other clients, but for reference the version is xterm-235-1.fc9.i386
Seems to happen with other applications as well, for instance xdvi. Very unlikely to be an xterm bug.
Aha, the log file says that it picks XAA, then it complains that XAA is unsupported on newer Radeons and I should use EXA instead. But I don't have a configuration file. I didn't _ask_ for XAA. Having XAA as the default, and then saying "Oh, the default is unsupported" is gibberish. I will see if I can temporarily cook up an EXA configuration file and re-test, but regardless of whether that works, one of two things needs to happen: 1. XAA becomes supported for newer hardware (unlikely since everyone seems to have decided that XAA is obsolete particularly for modern chipsets) 2. EXA becomes the default for newer hardware, so people with no configuration one way or the other get EXA, and any resulting bugs get found and fixed.
Yup, switching to EXA fixes the graphical corruption, and seems to have no ill effects. EXA should be the default for all hardware where XAA is not supported (R300 onwards I think).
As an extra data point, I've also seen graphical corruption (I have a Radeon X800 GTO). It's easily reproducible by opening 20 or so xterms, and grabbing one and moving it around vigorously. Switching to EXA (with Option "AccelMethod" "exa") fixes the problem for me entirely.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still a problem with F11. I'd happily change the version number to reflect this, but bugzilla doesn't seem to want to let me. Also, unlike in F9, the AccelMethod workaround listed above no longer fixes the problem. Attaching a screenshot. This was with a Radeon X850XT Platinum.
Created attachment 350319 [details] Screenshot
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.