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] /var/log/XFree86.0.log
Created attachment 425 [details] /var/log/Xorg.0.log Void previous attachment. Correct log file attached.
Created attachment 426 [details] /etc/X11/xorg.conf
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?
Option "XaaNoOffscreenPixmaps" fixes the corruption :-)
updating summary
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. Adding: ATIMach64WaitForIdle(pATI); to the end of SubsequentScreenToScreenCopy also makes the problem disappear completely for me. Any ideas?
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] Updated patch This patch provided by Marc Aurele La France completely resolved the problem for me.
(In reply to comment #13) > Created an attachment (id=5190) [edit] > 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. Thanks, george.
(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 7.2.
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!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.