Hello, I can reliably reproduce some minor display corruption on Fedora Core 2
using Mozilla 1.7. Continuously typing and erasing text in the URL text box,
causing the URL history dropdown to pop up and down repeatedly, eventually
results in some minor display corruption in the URL text box. I will attach a
short screen dump. The corruption appears to be minor, and it always gets erased
by the next keypress.
I believe that the corruption is caused by the driver/server, and not the
application, because if I set DISPLAY to a remote display, no corruption is
observed in the same situation.
Note: this is xorg 6.7.0 compiled for the x86_64 platform. SMP kernel.
Created attachment 423 [details]
Minor display corruption in Mozilla's URL text box.
Created attachment 424 [details]
Created attachment 425 [details]
Void previous attachment. Correct log file attached.
Created attachment 426 [details]
Created attachment 427 [details]
Output of lspci
does disabling XAA help? if so, could you test the various "XaaNo..." options
(described in the xorg.conf manpage) to see which part of XAA is to blame?
fixes the corruption :-)
Just another datapoint, I see exactly the same corruption with a mach64 card.
The problem shows itself when scaling a 1 pixel wide pixmap onto the screen.
The effect is visually identical to that shown in this report although it
persists when offscreen pixmaps are disabled too.
Disabling ScreenToScreen copy solves the problem.
to the end of SubsequentScreenToScreenCopy also makes the problem disappear
completely for me.
additional sync would be an acceptable workaround, but i'll see if i can do
better. this should get fixed in 6.9.
Whats the status of this bug using a current version of xorg?
I'm still on 6.8.2, but I don't seem to trigger this bug in 6.8.2.
I don't have any info on comment #9 -- I never experienced that variant of this bug.
Created attachment 5190 [details] [review]
This patch provided by Marc Aurele La France completely resolved the problem
(In reply to comment #13)
> Created an attachment (id=5190) 
> Updated patch
> This patch provided by Marc Aurele La France completely resolved the problem
> for me.
The attached patch consists of two parts:
* read-back cache invalidation
* copy throttling
Both parts have been merged in the following repository:
git//git.freedesktop.org/~libv/xf86-video-mach64. xf86-video-mach64 is still in
development but we intend to to have it distribution ready in time for 7.2.
The bug with scaling 1x1 pixmaps affects RENDER on mach64 EXA. My guess is that
RENDER commonly uses 1x1R pixmaps, which often get reduced to solid operations.
When the destination pixmap is read back by the CPU, corruption appears.
With the "cache invalidation" fix, mach64 EXA passes rendercheck.
The "copy throttling" fix has been applied but should be reverted if a better
fix is found.
(In reply to comment #14)
> Both parts have been merged in the following repository:
> git//git.freedesktop.org/~libv/xf86-video-mach64. xf86-video-mach64 is still in
> development but we intend to to have it distribution ready in time for 7.2.
This looks pretty good. Feel free to do an async mach64 release between now and
Ok to close this bug?
(In reply to comment #16)
> Ok to close this bug?
Personally, I think it's better to close this bug when
git//git.freedesktop.org/~libv/xf86-video-mach64 makes its first release.
Commited to HEAD. Thanks!