Red Hat Bugzilla – Bug 448450
graphical corruption, M24 1P Radeon Mobility X600 should have EXA default
Last modified: 2009-07-14 13:31:06 EDT
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):
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.
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.
Icon should not be overdrawn
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
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
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:
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]
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.