This bug report is the same as the one I opened downstream against KWin. See https://bugs.kde.org/show_bug.cgi?id=262824 That bug report contains all the information about my setup. The only thing I wanted to add was the software I have on my system, an ArchLinux box: ati-dri 7.9.0.git20101207-2 dri2proto 2.3-1 kernel26 2.6.36.3-1 libdrm 2.4.22-3 libgl 7.9.0.git20101207-2 mesa 7.9.0.git20101207-2 xf86-video-ati 6.13.2-2 xf86driproto 2.1.1-1 xorg-server 1.9.2-2 xorg-server-common 1.9.2-2 xorg-server-devel 1.9.2-2 I also tested the newer versions of the above packages with the same result: ati-dri 7.10-1 dri2proto 2.3-1 kernel26 2.6.37-1 libdrm 2.4.23-1 libgl 7.10-1 mesa 7.10-1 xf86-video-ati 6.13.2-2 xf86driproto 2.1.1-1 xorg-server 1.9.3.901-1 xorg-server-common 1.9.3.901-1 xorg-server-devel 1.9.3.901-1
Created attachment 42999 [details] glewinfo output
Created attachment 43000 [details] visualinfo output
Created attachment 43002 [details] kernel drm dmesg output
Created attachment 43004 [details] lspci -vv output
Created attachment 43005 [details] Xorg log file
Created attachment 43006 [details] screenshot after activating kwin desktop effects...
Created attachment 43007 [details] screenshot of asteroids3D game w/o kwin desktop effects
Machine Info ========== 2.6.37-ARCH #1 SMP PREEMPT Sat Jan 29 20:00:33 CET 2011 x86_64 Intel(R) Pentium(R) D CPU 3.20GHz GenuineIntel GNU/Linux Packages installed ============== kernel26 2.6.37-5 ati-dri 7.10-1 dri2proto 2.3-1 freeglut 2.6.0-1 glproto 1.4.12-1 libgl 7.10-1 mesa 7.10-1 xf86driproto 2.1.1-1 xf86-video-ati 6.14.0-1 xorg-xdriinfo 1.0.4-1 xorg-server 1.9.4-1 xorg-server-common 1.9.4-1 xorg-server-devel 1.9.4-1
Does the problem go away with the Mesa master branch?
(In reply to comment #9) > Does the problem go away with the Mesa master branch? Nope. It makes no difference. The problem has actually gotten worse since I got the updated packages I listed comment #8 vs the original report. And the issue stays the same with Mesa master branch from today. ati-dri-git 20110211-1 dri2proto-git 20110211-1 glproto-git 20110211-1 libdrm-git 20110211-1 libgl-git 20110211-1 mesa-git 20110211-1 Anyhow, attempting to enable any sort of compositing (aka desktop effects) in kwin results in a completely black window ontop which are some rectangular colored (green/red) artifacts. The 3D game is about as usable as it was in the attached screenshot.
This shows as "tearing"? on web pages, it appears to be the gallium driver not working well with Compiz. If I disable the gallium driver in Xorg.conf the tearing stops.
Could the fact that the kernel drm module seems to recognize my card incorrectly as an RV380 card, X600 Radeon card, have anything to do with my issues ? >>> [drm] initializing kernel modesetting (RV380 0x1002:0x5B60)
(In reply to comment #12) > Could the fact that the kernel drm module seems to recognize my card > incorrectly as an RV380 card, X600 Radeon card, have anything to do with my > issues ? > > >>> [drm] initializing kernel modesetting (RV380 0x1002:0x5B60) No, that's fine.
Created attachment 43757 [details] screenshot of activating compositing in kwin II
Does using Xv fix the kwin issues? A user reported on IRC that using Xv seems to fix the GL issues he was having which implies we are missing some state in the 3D driver that the 2D driver sets.
Created attachment 43770 [details] xvinfo output
(In reply to comment #15) > Does using Xv fix the kwin issues? A user reported on IRC that using Xv seems > to fix the GL issues he was having which implies we are missing some state in > the 3D driver that the 2D driver sets. Well Xv is most definitely enabled on my system, but I fail to see how that helps with the kwin composting issue. Perhaps, I misunderstood your question ? I have attached the output of the xvinfo just the same. If that was what you were suggesting, then no it does not help with the kwin issues. On the other hand, if you were asking whether or not changing the compositing mode in kwin from "OpenGL" to "XRender" helps then the answer would yes for the most part. Unfortunately many desktop effects won't work in that mode. Anyhow, I rather doubt that was what you wanted to know.
(In reply to comment #17) > > Well Xv is most definitely enabled on my system, but I fail to see how that > helps with the kwin composting issue. Perhaps, I misunderstood your question ? > I have attached the output of the xvinfo just the same. If that was what you > were suggesting, then no it does not help with the kwin issues. Use Xv; playback a video using Xv. Xv uses the 3D engine just like OpenGL. If the 3D driver is not properly emitting some 3D state, but Xv is, OpenGL should work properly after you've used Xv since the missing state will now be programmed properly. xvinfo is not enough, you actually have to render some video.
(In reply to comment #18) > (In reply to comment #17) > > > > Well Xv is most definitely enabled on my system, but I fail to see how that > > helps with the kwin composting issue. Perhaps, I misunderstood your question ? > > I have attached the output of the xvinfo just the same. If that was what you > > were suggesting, then no it does not help with the kwin issues. > > Use Xv; playback a video using Xv. Xv uses the 3D engine just like OpenGL. If > the 3D driver is not properly emitting some 3D state, but Xv is, OpenGL should > work properly after you've used Xv since the missing state will now be > programmed properly. xvinfo is not enough, you actually have to render some > video. Okay, when I do that then there is a very minor improvement. The artifacts shown in the screen shots above are no longer there, but I still get a completely dark screen with only the mouse pointer showing...
Problem is still there with the following updated packages: libgl 7.10.3-1 ati-dri 7.10.3-1 libdrm 2.4.25-1 xf86-video-ati 6.14.1-1 xorg-server-common 1.10.2-1 xorg-server-utils 7.6-2 xorg-server 1.10.2-1 xf86driproto 2.1.1-1 Is there anyway to debug such that I can try ? I do not mind getting down and dirty if it means getting this issue resolved. OpenGL support has not worked on my machine ever since the ati driver was switched to the Gallium version.
I'm on ubuntu 11.04 now and unity is unusable. If I boot straight to it but on my dual boot system if I boot windows xp then simply restart the laptop unity works just fine except with "tearing" in web browser. So Yes you may be right some setup state is missing in the driver. But that still will not I believe fix the "tearing".
Maybe you are having interrupt problems. run: cat /proc/interrupts and see if you see the interrupts increasing for radeon. You might try the following options on the kernel command line in grub: pci=nomsi irqpoll
Added both your options and looking at the cat command can see no difference and in fact cold boot still results in an unusable unity. A windows restart is still OK.
(In reply to comment #23) > Added both your options and looking at the cat command can see no difference > and in fact cold boot still results in an unusable unity. A windows restart is > still OK. I get the same display corruption with those options as well set as well. It does not matter if you set both or one at a time. For me the corruption is now better than what it was a couple of revisions back, but it is still unusable.
Seems to be finally fixed in Mesa 7.11. Dunno what the cause was, but it works fine for me on the hardware and driver I reported with the shinny new Mesa 7.11. Big thanks for whomever fixed this problem.
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.