Comment 43 for bug 486154

> Can you be precise about what you're doing to enable/disable compiz so I can try the same tests?

I had been switching between "None" (metacity) and "Normal" (compiz) in the Visual Effects panel of Appearance Preferences. I just figured out that I can also switch by running "compiz --replace" and "metacity --replace". As far as I can tell, these two methods are the same. But to be sure what's going on, perhaps we should use the command line method from here on out.

As best I can tell, the difference in running processes is:
1) When I first log in, "metacity" is running as a child of "gnome-session".
2) After I switch to compiz (using the Appearance Preferences), metacity is no longer running. Instead, "/bin/sh /usr/bin/compiz --replace" is running at the top level, with child process "/usr/bin/compiz.real --ignore-desktop-hints --replace --indirect-rendering --replace move resize place decoration animation ccp", which has child "/bin/sh -c /usr/bin/compiz-decorator", which has child "/usr/bin/gtk-window-decorator". (Additionally /usr/share/jockey/jockey-backend was started as a separate process. I don't know if this was related or not.)
3) Switching back to metacity, "metacity --replace" is now running at the top level. "compiz" and "compiz.real" have been killed, though "compiz-decorator" and "gtk-window-decorator" (and "jockey-backend") are still running. Switching to compiz again will apparently use the existing decorator processes rather than starting new ones.

So, while compiz seems to have several processes running, the only process unique to metacity is in fact "metacity"

I just tried running "killall metacity" (while using metacity, of course). Sure enought, the window title bars disappeared. So did the bell.ogg sound. However, it was NOT replaced by the PC speaker beep! (Instead I got silence.) System bell events were still being generated (as per xkbevd) and the speaker still worked (as per beep). Starting compiz from this state was enough to restore the beep on system bell events. Perhaps there is some sort of negotiation between X and the window managers about what to do with these events? Maybe I should look in compiz's code to see if there's a section where it tells X not to sent system bell events its way.