Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Screen blink periodically with dynamic wallpapers and compiz|
|Product:||[Fedora] Fedora||Reporter:||Carlos Vassalo <opossum1er>|
|Component:||xorg-x11-server||Assignee:||Kristian Høgsberg <krh>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||adel.gadllah, bnocera, eparis, guillaume, juankprada, krh, mohd.izhar.firdaus, nushio, otaylor, selinux, wwoods, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-06 17:36:08 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Carlos Vassalo 2008-04-07 04:11:10 EDT
Description of problem: When I activate the dynamic wallpaper (Infinity of F8 theme or Waves of F9 theme) my screen blink periodically (approximately 1 minute): Metacity and dynamic waves wallpaper -> OK Compiz-fusion and simple wallpaper -> OK Compiz-fusion and dynamic Infinity wallpaper -> KO Compiz-fusion and dynamic waves wallpaper -> KO Additional info: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
Comment 1 David Zeuthen 2008-04-07 13:39:36 EDT
Uhm. This is filed against the wrong component.
Comment 2 Adel Gadllah 2008-04-07 16:35:44 EDT
And still is ... moving to compiz.
Comment 3 Eric Paris 2008-04-07 16:52:37 EDT
01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility X600] Default F9 Install showing the same thing. (is the default wallpaper dynamic?)
Comment 4 Adel Gadllah 2008-04-08 03:26:29 EDT
(In reply to comment #3) > 01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility > X600] > > > Default F9 Install showing the same thing. (is the default wallpaper dynamic?) Yes it is. Can you or Carlos test this scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=556243 But please make sure that gnome-settings-daemon is restarted (ex: reboot or kill and restart it).
Comment 5 Adel Gadllah 2008-04-08 03:32:56 EDT
Created attachment 301610 [details] Patch used (don't draw to root window when a cm is running)
Comment 6 Carlos Vassalo 2008-04-08 09:26:24 EDT
patch applied. Tests in progress... ;-)
Comment 7 Carlos Vassalo 2008-04-08 10:41:05 EDT
Same problem with this version of gnome-settings-daemon.
Comment 8 Eric Paris 2008-04-08 23:29:48 EDT
install gnome-settings-daemon-2.22.1-0.2008.03.26.6.fc9.i386 reboot same problem
Comment 9 Matěj Cepl 2008-04-14 18:39:19 EDT
*** Bug 442121 has been marked as a duplicate of this bug. ***
Comment 10 Jesse Keating 2008-04-18 10:55:36 EDT
Moving to X blocker.
Comment 11 Dave Airlie 2008-04-27 21:32:33 EDT
can you see if this happens with latest intel driver in F9?
Comment 12 Juan Manuel Rodriguez 2008-04-28 00:05:18 EDT
Dave: I'm using the latest intel driver in F9, and still have the same issue. Whats worse is that enabling desktop effects closed/crashed the gtk-window-decorator. Everything was still wobbly, and screen still flickered once every minute or so. I'll try to get a stacktrace and attach it in a moment.
Comment 13 Juan Manuel Rodriguez 2008-04-28 00:07:39 EDT
Here's the info I could grab. If anyone knows a better way to get a stacktrace, let me know. gtk-window-decorator: Screen 0 on display ":0.0" already has a decoration manager; try using the --replace option to replace the current decoration manager. compiz (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format compiz (core) - Warn: No GLXFBConfig for depth 32 compiz (core) - Warn: No GLXFBConfig for depth 32 compiz (core) - Warn: No GLXFBConfig for depth 32
Comment 14 Carlos Vassalo 2008-04-28 10:53:24 EDT
F9 up to date, same problem.
Comment 15 Jeremy Katz 2008-04-29 16:31:44 EDT
I'm still seeing this too (well, until I fall back to metacity because it's pretty unusable with the flicker). This is incredibly visible in a feature that we talk about a lot.
Comment 16 Carl Worth 2008-05-01 15:57:54 EDT
I'm seeing this with the latest Intel driver, (oh---but now that I look closer it looks like I'm only seeing it with DRI2 enabled). Also, for anybody debugging this, besides the automatic flicker that doesn't require any user intervention, (except waiting for it to happen), it looks like it's easy to force the bug to manifest itself by changing the desktop background. Specifically, changing between two image folders causing the single quick blink, while switching between two static images causes a *lot* of flashing, (all windows disappear, old image is painted, new image is painted, maybe a quick blink, then windows reappear). I don't know if that's one bug or two, but it's definitely not a smooth experience. -Carl
Comment 17 Behdad Esfahbod 2008-05-01 20:12:12 EDT
*** Bug 440982 has been marked as a duplicate of this bug. ***
Comment 18 Behdad Esfahbod 2008-05-01 20:37:47 EDT
I debugged this today. Found the bug and an easy patch. Attaching for testing.
Comment 19 Behdad Esfahbod 2008-05-01 20:45:48 EDT
Created attachment 304349 [details] patch for gnome-desktop The bug was pretty simple: - Nautilus calls eel to set background - Eel first sets its window's background, then calls gnome-desktop's libgnomeui to set the root window's background too (such that when nautilus is killed, the background on the root window is correct) - gnome-desktop's gnome_bg_set_pixmap_as_root() does this: /* Set the root pixmap, and properties pointing to it. We * do this atomically with XGrabServer to make sure that * we won't leak the pixmap if somebody else it setting * it at the same time. (This assumes that they follow the * same conventions we do) So it does: 1) Grab the server 2) Get pixmap id of current background. If successfull, destroy it. 3) Set new background 4) Ungrab server Now to destroy a resource without risking disconnecting from the server, one needs to push/pop an error trap around the operation. For error traps to actually work, one needs to flush before popping the trap. Net result is, that function does: "grab server; do some stuff; flush; do some other stuff; ungrab server". Grabbing the server means the compositing manager is not run/scheduled. The flush though also flushes previous requests to change the background of the nautilus window. So when we finally ungrab, it's a mess for the compositor to catch up, and all the flicker happens. Solution is simple: do the pixmap destroy part after ungrabbing the server. That's what the patch does. Will submit upstream too.
Comment 20 Behdad Esfahbod 2008-05-01 21:13:26 EDT
Humm, that doesn't seem to do it. It's nondeterministic at best.
Comment 21 Matthias Clasen 2008-05-01 21:27:31 EDT
Behdad, if the server grab locking out the compositor is the root cause of the problem, can we just ditch the grab ? I mean, what other apps do we expect to set the root pixmap nowadays, xearth ?!
Comment 22 Bill Nottingham 2008-05-02 15:34:27 EDT
Given normal blocker criteria, I don't see this as a blocker at this point. Moving to target.
Comment 23 Will Woods 2008-05-02 21:05:45 EDT
The patch in comment #19 seems to work just fine for me. Switching between different static backgrounds (as suggested in comment #16) is smooth and flawless, and there's no flicker with the slideshow background. Behdad, are you *sure* this patch isn't right?
Comment 24 Danny Baumann 2008-05-03 07:36:35 EDT
The patch in comment #19 seems to work fine for me as well.
Comment 25 Matěj Cepl 2008-05-03 09:11:08 EDT
*** Bug 444380 has been marked as a duplicate of this bug. ***
Comment 26 Owen Taylor 2008-05-04 21:01:11 EDT
I spent some time looking into the issue, and here's my understanding of what is happening: * gnome-desktop/libgnome-desktop/gnome-bg.c:gnome_bg_set_pixmap_as_root() calls XClearWindow (display, RootWindow (display, screen_num)); * That should have no effect since compiz and the metacity compositor use the "composite overlay window", a magic window that is on top of everything, and should obscure everything. * However, for reasons that I don't completely understand, the composite overlay window is not clipping drawing on the root window; if I, for example, draw a rectangle on the root window using GDK, that appears directly on the screen. Debugging the X server, I can also see that the root window is unclipped. My best guess at this point is that the composite overlay window got caught in the XCompositeRedirectSubwindows() call, and that broke the clip processing. I think Behdad's patch likely doesn't do anything at all, but in some restarts the clipping may be fine, and in others not fine, so there is a placebo effect.
Comment 27 Owen Taylor 2008-05-04 21:02:41 EDT
Changing component based on my understanding of the location of the issue.
Comment 28 Owen Taylor 2008-05-05 00:51:17 EDT
Debugged along with Keith Packard, he came up with a patch which should be going into Xorg git soon. Upstream bug is: https://bugs.freedesktop.org/show_bug.cgi?id=15823
Comment 29 Tom London 2008-05-05 18:34:58 EDT
Works for me with xorg-x11-server-*-188.8.131.521-28.20080415.fc9
Comment 30 Matěj Cepl 2008-05-06 13:30:52 EDT
Carlos, could you still reproduce this with the Xorg server from the above shown package?
Comment 31 Carlos Vassalo 2008-05-06 16:08:32 EDT
It seems to be ok for me too with xorg-x11-server-Xorg.x86_64 0:184.108.40.2061-28.20080415 package. Great job all, see you on may 13th... ;-) Thank you