Bug 441219 - Screen blink periodically with dynamic wallpapers and compiz
Summary: Screen blink periodically with dynamic wallpapers and compiz
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Kristian Høgsberg
QA Contact: Fedora Extras Quality Assurance
: 440982 442121 444380 (view as bug list)
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
Reported: 2008-04-07 08:11 UTC by Carlos Vassalo
Modified: 2018-04-11 18:16 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-06 21:36:08 UTC
Type: ---

Attachments (Terms of Use)
Patch used (don't draw to root window when a cm is running) (761 bytes, patch)
2008-04-08 07:32 UTC, Adel Gadllah
no flags Details | Diff
patch for gnome-desktop (1.16 KB, patch)
2008-05-02 00:45 UTC, Behdad Esfahbod
no flags Details | Diff

Description Carlos Vassalo 2008-04-07 08:11:10 UTC
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 17:39:36 UTC
Uhm. This is filed against the wrong component.

Comment 2 Adel Gadllah 2008-04-07 20:35:44 UTC
And still is ... moving to compiz.

Comment 3 Eric Paris 2008-04-07 20:52:37 UTC
01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility

Default F9 Install showing the same thing.  (is the default wallpaper dynamic?)

Comment 4 Adel Gadllah 2008-04-08 07:26:29 UTC
(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: 

But please make sure that gnome-settings-daemon is restarted (ex: reboot or kill
and restart it).

Comment 5 Adel Gadllah 2008-04-08 07:32:56 UTC
Created attachment 301610 [details]
Patch used (don't draw to root window when a cm is running)

Comment 6 Carlos Vassalo 2008-04-08 13:26:24 UTC
patch applied. Tests in progress... ;-)

Comment 7 Carlos Vassalo 2008-04-08 14:41:05 UTC
Same problem with this version of gnome-settings-daemon.

Comment 8 Eric Paris 2008-04-09 03:29:48 UTC
install gnome-settings-daemon-2.22.1-0.2008.03.26.6.fc9.i386
same problem

Comment 9 Matěj Cepl 2008-04-14 22:39:19 UTC
*** Bug 442121 has been marked as a duplicate of this bug. ***

Comment 10 Jesse Keating 2008-04-18 14:55:36 UTC
Moving to X blocker.

Comment 11 Dave Airlie 2008-04-28 01:32:33 UTC
can you see if this happens with latest intel driver in F9?

Comment 12 Juan Manuel Rodriguez 2008-04-28 04:05:18 UTC
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 04:07:39 UTC
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 14:53:24 UTC
F9 up to date, same problem.

Comment 15 Jeremy Katz 2008-04-29 20:31:44 UTC
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 (Ampere) 2008-05-01 19:57:54 UTC
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.


Comment 17 Behdad Esfahbod 2008-05-02 00:12:12 UTC
*** Bug 440982 has been marked as a duplicate of this bug. ***

Comment 18 Behdad Esfahbod 2008-05-02 00:37:47 UTC
I debugged this today.  Found the bug and an easy patch.  Attaching for testing.

Comment 19 Behdad Esfahbod 2008-05-02 00:45:48 UTC
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-02 01:13:26 UTC
Humm, that doesn't seem to do it.  It's nondeterministic at best.

Comment 21 Matthias Clasen 2008-05-02 01:27:31 UTC
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 19:34:27 UTC
Given normal blocker criteria, I don't see this as a blocker at this point.
Moving to target.

Comment 23 Will Woods 2008-05-03 01:05:45 UTC
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 

Behdad, are you *sure* this patch isn't right? 

Comment 24 Danny Baumann 2008-05-03 11:36:35 UTC
The patch in comment #19 seems to work fine for me as well.

Comment 25 Matěj Cepl 2008-05-03 13:11:08 UTC
*** Bug 444380 has been marked as a duplicate of this bug. ***

Comment 26 Owen Taylor 2008-05-05 01:01:11 UTC
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-05 01:02:41 UTC
Changing component based on my understanding of the location of the issue.

Comment 28 Owen Taylor 2008-05-05 04:51:17 UTC
Debugged along with Keith Packard, he came up with a patch which should
be going into Xorg git soon. Upstream bug is:


Comment 29 Tom London 2008-05-05 22:34:58 UTC
Works for me with xorg-x11-server-*-

Comment 30 Matěj Cepl 2008-05-06 17:30:52 UTC
Carlos, could you still reproduce this with the Xorg server from the above shown

Comment 31 Carlos Vassalo 2008-05-06 20:08:32 UTC
It seems to be ok for me too with xorg-x11-server-Xorg.x86_64
0: package.

Great job all, see you on may 13th... ;-)

Thank you

Comment 32 Matěj Cepl 2008-05-06 21:36:08 UTC
(In reply to comment #31)
> It seems to be ok for me too with xorg-x11-server-Xorg.x86_64
> 0: package.


> Great job all, see you on may 13th... ;-)


Note You need to log in before you can comment on or make changes to this bug.