Current xf86-video-ati driver causes a strange flickering effect when kwin effects are activated. The flickering happens only when an animation is in progress (e.g, zooming out the desktop, the "exposé" effect, the logout) but not when no effect is active. It does seem to be related to SS or a wrong mode; I've taken a small video to show the bug: http://www.youtube.com/watch?v=ZLLZM4bMYus (this is the logout effect, which should fade-out the destkop). The software stack: DDX: 6.14.0 from git libdrm: 2.4.23 (debian) mesa: 7.10 (debian) xserver: 1.9.3.902 (debian) kernel: 2.6.37, KMS enabled HW is a mobility HD2600 (M76); I tried with and without color tiling, pageflip is not in use since kernel does not support it. The same software setup works fine on my desktop which as a RV770. Last known working version is 6.13.99... which is a bit vague, but I didn't track the exact git revision :( I can try and bisect if you think it can be useful.
Created attachment 42988 [details] Xorg log for 6.13.99
Created attachment 42989 [details] Xorg log for 6.14.99
Can you bisect?
Still haven't found time to bisect, but I've noticed that with 'high' power profile the effect is less noticeable than with 'low' (which is what I usually use).
I think the following bugs are probably related: bug 33929 bug 33952 bug 33943 bug 33963
(In reply to comment #5) > I think the following bugs are probably related: > bug 33929 > bug 33952 > bug 33943 > bug 33963 I disagree, I don't see any corruption, just that strange flickering effect and only when an effect is running. The original bug report contains a typo: it does *not* seem related to a bad mode or a PLL issue. The bisection has been inconclusive, 6.13.0 locks up the machine, 6.13.1 shows the flickering; in the middle I encountered a crash in DRI2CopyRegion. The good driver is marked 6.13.99; is it possible that an external component (X, or libdrm) makes the difference at build time? Yes, I did a make clean before testing :) This is the log (lock up is marked as good under the assumption that the working driver was compiled _after_ that point), just in case: There are only 'skip'ped commits left to test. The first bad commit could be any of: ea37d24b1b6d4cbcf73e680846de25b72af216e3 f7a91ece264af9f3fd2fc18e99aefcda93ce9f5c 800cb2088fec698d0626063a9ab198ff534938c0 We cannot bisect more! git bisect start # good: [fb7911912e60b2cdbc2152b96847775b767ca3ef] bump version for release git bisect good fb7911912e60b2cdbc2152b96847775b767ca3ef # bad: [ad999e633ff41d27eed9d2c6535e163a7181b0bd] set version for release git bisect bad ad999e633ff41d27eed9d2c6535e163a7181b0bd # good: [766024dcc61c83490540910ce752f9bfe6dddba4] r3xx-r5xx: fix texturing with small macrotiled pixmaps git bisect good 766024dcc61c83490540910ce752f9bfe6dddba4 # good: [a2528a734c1d4e8639c49e5d222e3630a93ffbfd] r6xx/r7xx accel: remove some duplicate emits and minor clean up git bisect good a2528a734c1d4e8639c49e5d222e3630a93ffbfd # skip: [f7a91ece264af9f3fd2fc18e99aefcda93ce9f5c] Convert x(c)alloc/xfree to m/calloc/free. git bisect skip f7a91ece264af9f3fd2fc18e99aefcda93ce9f5c # bad: [800cb2088fec698d0626063a9ab198ff534938c0] DRI2: Fix up confusion between windows and pixmaps. git bisect bad 800cb2088fec698d0626063a9ab198ff534938c0 # good: [4651d77211b508cb6b76931807780e317f232220] radeon: fix depth 16 with ums git bisect good 4651d77211b508cb6b76931807780e317f232220 # skip: [ea37d24b1b6d4cbcf73e680846de25b72af216e3] radeon: fix support for 1.9 server master. git bisect skip ea37d24b1b6d4cbcf73e680846de25b72af216e3 # good: [fdd8ecafd054f65842351aee6ee6fba7af6613b2] r6xx/r7xx: macro safety fixes git bisect good fdd8ecafd054f65842351aee6ee6fba7af6613b2
Debian package for the DDX shows the same problem. I briefly tested the live image from Fedora test day[1], and gnome shell worked fine with all its effects. [1] https://fedoraproject.org/wiki/Test_Day:2011-02-23_Radeon
Now testing gnome shell on my debian system and DDX from git: everything is good. So I guess it's kde/kwin fault?
Now running KDE 4.6: the bug is gone, I guess that the problem was in the old KDE, not in the video driver. Closing.
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.