Scrolling inside applications (Firefox, Eclipse, Konsole, ...) causes corruption in the redrawn area. The same problem once happened with radeonhd driver and xorg 1.7.1 (bug 24771). See bug 24771 for screenshots. Messages like "*ERROR* sending pending buffer" don't occur this time. radeon driver version is 6.13.0 but also happens with 6.12.6 mesa version is 7.8.1 libdrm version is 2.4.20 My card is a HD4850
Hi, I second this bug report, but only when KMS is disabled. I am using kernel 2.6.33 with xorg 1.8, mesa 7.8.1, libdrm 2.4.20 and xf86-video-ati 6.13.0 (on Archlinux and the xorg18 repo that packages all of this except kernel which is in the core repo). I will attach my dmesg and xorg.log. I will also add on Monday another set of dmesg and xorg.log from a laptop where the problem is a lot more visible.
Created attachment 35133 [details] dmesg, xorg 1.8, kernel 2.6.33, mesa 7.8.1, libdrm 2.4.20, xf86-video-ati 6.13.0, KMS disabled
Created attachment 35134 [details] Xorg.0.log, xorg 1.8, kernel 2.6.33, mesa 7.8.1, libdrm 2.4.20, xf86-video-ati 6.13.0, KMS disabled
Same here. KMS _not_ enabled, using a compositing manager (metacity's own). I thought it only happened with compositing enabled, but I managed to get a corruption without compositing too, but it happens far less often (on a long page in my browser ; it happens on almost everything that scroll with compositing enabled). I use Debian sid, with a HD3200 (integrated into 780G chipset). Dual-screen setup. Using radeon driver 6.13.0, Xorg 1.7.6.901, Mesa 7.7.1, libdrm 2.4.18, kernel 2.6.32 (i.e. every latest sid version ATM). To describe how it looks, it often happens when scrolling with the mouse wheel, and it feels like sometime the application miss a step, but then everything that is redrawn is such as it is offset by some number of pixels (like, the size of a wheel step maybe ?). Then the app displays a mix of correct and offset pixmaps, which renders it almost unusable. Trying to scroll a lot sometime triggers enough redraw so the app is usuable again, but triggering redraws at the top or bottom of the page is difficult. For me, the importance of this bug is rather "high".
Created attachment 35289 [details] My dmesg, radeon driver 6.13.0, Xorg 1.7.6.901, Mesa 7.7.1, libdrm 2.4.18, kernel 2.6.32
Created attachment 35290 [details] My xorg.conf, maybe badly tweaked
Hello: This is the very same problem as I'm experiencing. Same graphics stack as Benjamin stated. rv500 family card. I'd also notice that xserver package in Debian is 1.7rc1 plus a patch taken from 1.7rc2: “exa: handle pixmap create/destroy in lower layers” I've done some tests tweaking xorg parameters, and I've found that setting "EXANoDownloadFromScreen" avoids somehow this corruption, yet leaving another different one, reported in another bug which I'm unable to find right now. As a sidenote I also find that enabling this worsen performance in a noticeable manner. For instance, after doing some work on a desktop, switching to another one takes approximately half a second** I've also tried AccelDFS "off"(on its own) which also avoids the artifacts explained in this bug, but it has an impact on performance slightly worst than the previous option. This is very subjective, so maybe this appreciation is wrong. Finally, I've also tried "exaNoMigration" (to be confirmed soonish) but this option doesn't result in any outcome. **Warning: very inaccurate measurement ;) Regards,
The same (or similar) problem here. RV710 [Radeon HD 4350], without KMS and with "RenderAccel" set to "False". There are artefacts in the browser and pdf viewer on scrolling. The best way to reproduce the problem for me is to open a large pdf file in okular, go to the end of the document and then try to scroll it up by holding PAGE UP key pressed for a few seconds, then releasing it and immediately pressing ARROW UP key a few times. Repeating this sequence triggers this bug eventually (typically in less than 10 tries). Bisecting reveals that this regression has been introduced by the following commit: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=53ac06161eb2 From 53ac06161eb2b8cffb1b88e24a9a21cfd12e5883 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexdeucher@gmail.com> Date: Tue, 23 Mar 2010 17:34:38 +0000 Subject: r6xx+ EXA/Xv: add a R600SetAccelState function This moves CS bo checking and alignment checks into a central location. It also cleans up the code.
Created attachment 41314 [details] corruption-on-scrolling-in-pdf-viewer.png This is a screenshot showing how it typically looks for me. xf86-video-ati-6.12.x works fine.
Looks like Bug 28607 could be a duplicate of this one.
I think that I could also reproduce this bug with any driver release at or after 6.13.0. Compiling from sources using revision 7a044472dfea7cf05ba4c2b87be30e94e2ae0b62 does indeed makes the bug go away, but the problem is that that revision is quite old. Also, it's not possible to just 'git revert' that revision, because it's a sufficiently large change and there are subsequent changes dependent on it.
And another detail - my report comes from FreeBSD (amd64 arch), so the non-KMS code paths are exercised in my case.
Is this still an issue with a newer driver/kernel?
The question implies that it is Linux specific... But here is a FreeBSD (UMS, obviously) report: I don't seem to be able to reproduce this issue although I had it before. My X environment: xorg-server: 1.10.6 xf86-video-ati: 6.14.3 mesa: 7.11.2
Please reopen if you still have issues.
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.