2.6.26.2 kernel means no GEM support in drm. intel driver, mesa, drm userspace library and xserver are all from git master branches. When I start compiz the screen becomes corrupted (largely black with more or less random pixels where the windows used to be). It's hard to describe so I'll try to make a screenshot. When I kill compiz and start metacity everything goes back to normal. dmesg contains (this is after I start up Xorg, run compiz / glxgears and then shut down Xorg): [drm:i915_getparam] *ERROR* Unknown parameter 5 [drm:i915_getparam] *ERROR* Unknown parameter 5 [drm:i915_getparam] *ERROR* Unknown parameter 5 [drm:i915_getparam] *ERROR* Unknown parameter 5 [drm:i915_getparam] *ERROR* Unknown parameter 5 mtrr: no MTRR for e0000000,10000000 found While Xorg runs, I don't see any such entry in /proc/mtrr. Xorg.1.log contains this (full log attached): exaCopyDirty: Pending damage region empty! I thought it would be related, but commenting out the following REGION_INTERSECT() in exa/exa_migration.c:exaCopyDirty() didn't help. So I don't think that is related (though probably still a bug somewhere).
Created attachment 18393 [details] Xorg log
Created attachment 18394 [details] screenshot showing the corruption I managed to make a screenshot. What you see used to be an empty desktop (the default Xorg background pattern) and on top of that an xterm window. All compiz features work (moving/resizing windows etc), cursor is not corrupted. When compiz draws something with opengl (such as when I resize the window compiz draws a blue quad using opengl), that is rendered correctly. It's only the windows that have corrupted contents. So it looks like opengl itself works fine and the bug is only affecting the GLX_tfp implementation.
Shuang, can you reproduce this?
(In reply to comment #3) > Shuang, can you reproduce this? > I've tried that, the screen go to black when I enable compiz on GM965. but 3D app (In reply to comment #2) > Created an attachment (id=18394) [details] > screenshot showing the corruption > > I managed to make a screenshot. What you see used to be an empty desktop (the > default Xorg background pattern) and on top of that an xterm window. > > All compiz features work (moving/resizing windows etc), cursor is not > corrupted. When compiz draws something with opengl (such as when I resize the > window compiz draws a blue quad using opengl), that is rendered correctly. It's > only the windows that have corrupted contents. So it looks like opengl itself > works fine and the bug is only affecting the GLX_tfp implementation. > I tried this on GM965, with kernel 2.6.23.1-42.fc8, enable compiz will make screen to to black, which is bug #16394. And I accidentally see this line "exaCopyDirty: Pending damage region empty!" though I can't triger it again. And click on the menu, I can see some part of corrputed rendering.
(In reply to comment #2) > So it looks like opengl itself works fine and the bug is only affecting the > GLX_tfp implementation. Maybe zero-copy tfp has been broken again. You can try the workaround from http://bugs.freedesktop.org/show_bug.cgi?id=14441#c9 to verify this. > exaCopyDirty: Pending damage region empty! The damage layer doesn't skip operations with an empty destination region, so this is usually harmless.
(In reply to comment #5) > (In reply to comment #2) > > So it looks like opengl itself works fine and the bug is only affecting the > > GLX_tfp implementation. > > Maybe zero-copy tfp has been broken again. You can try the workaround from > http://bugs.freedesktop.org/show_bug.cgi?id=14441#c9 to verify this. The workaround indeed fixes it.
I'd lost airlied's patches in a merge, which would lead to issues like this. Should be fixed now.
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.