Bug 448450 - graphical corruption, M24 1P Radeon Mobility X600 should have EXA default
graphical corruption, M24 1P Radeon Mobility X600 should have EXA default
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
i686 Linux
low Severity low
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-26 20:10 EDT by Nick Lamb
Modified: 2018-04-11 13:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 13:31:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg log file on affected system (49.53 KB, text/plain)
2008-05-28 16:02 EDT, Nick Lamb
no flags Details
Screenshot (10.58 KB, image/png)
2009-07-02 13:54 EDT, Tethys
no flags Details

  None (edit)
Description Nick Lamb 2008-05-26 20:10:56 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):

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
Comment 1 Matěj Cepl 2008-05-27 06:07:19 EDT
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.
Comment 2 Nick Lamb 2008-05-28 16:02:13 EDT
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.
Comment 3 Nick Lamb 2008-05-28 17:21:53 EDT
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
Comment 4 Miroslav Lichvar 2008-05-29 06:33:09 EDT
Seems to happen with other applications as well, for instance xdvi. Very
unlikely to be an xterm bug.
Comment 5 Nick Lamb 2008-07-02 18:22:05 EDT
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.
Comment 6 Nick Lamb 2008-07-03 17:00:46 EDT
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).
Comment 7 Tethys 2008-10-21 13:12:31 EDT
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.
Comment 8 Bug Zapper 2009-06-09 21:13:38 EDT
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: 
Comment 9 Tethys 2009-07-02 13:53:27 EDT
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.
Comment 10 Tethys 2009-07-02 13:54:18 EDT
Created attachment 350319 [details]
Comment 11 Bug Zapper 2009-07-14 13:31:06 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.