Created attachment 63080 [details] screenshot This is Gnome fallback with metacity and compositing enabled. See attachment. Kind of offtopic: I get a reproducible freeze with 3.2 kernel (without rc6 or anything), 3.4 is ok. Should I report? System: - Debian unstable - Metacity with Compositing enabled - Sandy Bridge: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) - 3.4 kernel - xf86-video-intel: 515c8b19d638d4a811b159 (2012-06-15 14:41:14)
On Fri, Jun 15, 2012 at 8:00 PM, <bugzilla-daemon@freedesktop.org> wrote: > Kind of offtopic: I get a reproducible freeze with 3.2 kernel (without rc6 or > anything), 3.4 is ok. Should I report? Too many big known issues for snb on 3.2, so likely not worth it.
That looks very much like a Damage bug between your xserver and your compositing manager. Does debian have xserver-1.12 packaged in experimental yet? That would be one thing to test. (Depending on whether they have the 1.12 before the damage bug was reintroduced...)
(In reply to comment #1) > On Fri, Jun 15, 2012 at 8:00 PM, <bugzilla-daemon@freedesktop.org> wrote: > > Kind of offtopic: I get a reproducible freeze with 3.2 kernel (without rc6 or > > anything), 3.4 is ok. Should I report? > > Too many big known issues for snb on 3.2, so likely not worth it. OK, thanks. (In reply to comment #2) > That looks very much like a Damage bug between your xserver and your > compositing manager. Does debian have xserver-1.12 packaged in experimental > yet? That would be one thing to test. (Depending on whether they have the 1.12 > before the damage bug was reintroduced...) I have this one running: X.Org X Server 1.12.1.902 (1.12.2 RC 2)
Uh, sorry, I was too quick to blame sna here. The same happens with uxa.
Christoph, do you know a way of reliably reproducing this? I'm pretty sure it is a damage bug, but without tracing it, it is very hard to know where.
It only happens with metacity(composited) if that helps. Besides the nautilus dragging there are missing redraws in any java GUI app (eclipse/net beans) and flash. btw. thanks for fixing video tearing :)
Some downstream bug reports I found: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685838 https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/1015277 Would a debug log help, or something like xtrace?
The bug can't be reproduced on my side. Our test environment as following: Mesa: (9.1)f00ae9c773dc944f0d900ef5c50c3b417ad95e84 Xserver: (server-1.13-branch)xorg-server-1.13.4 Xf86_video_intel:(master)2.21.7-5-g87295b1ef85505689ce326137c2794230fb3f35f Cairo:(master)631bf299256e11a17511977f357e0353fb5615f7 Libva_intel_driver:(master)31caada2967b94705d78ab7f6d07965ad7f13d42 Kernel:(drm-intel-fixes) 3598706b52cb45ba0a9e8aa99ce5ac59140f2b8b Os: Fedora17
I can still reproduce with debian unstable. But since this is likely a metacity problem and metacity will vanish with the fallback session, feel free to close.
Right, I am pretty sure it is a bug in metacity not repainting the background correctly - I was keeping it open in case I ever managed to reliably reproduce it so that I could rule out an Xserver bug.
Ok, I understand what is going on here now. There has been no call to SetRootWindowBackground (which would be via a XChangeWindowAttributes by one of the clients to set the root pixmap) and so the root->backgroundState has been left as None due to the canDoBgNoneRoot hack to preserve the fbcon during X startup. As the root->backgroundState == None, when a window moves the expose event on the root window is ignored (though miClearWindow calling miPaintWindow). Ultimately this bug can only be prevented if gdm sets its final presentation pixmap as the background on the root window.
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.