Cannot switch to Compiz if Metacity compositor is enabled

Metacity is not giving up control of the compositor selection.

This is not, as far as I can see, a Metacity problem. Compiz is failing to start because it sees another compositor is running. I am not closing the metacity bug here because I may be wrong, but I will check when I'm less immediately busy.

Compiz code for taking over as composite manager:
        XSetSelectionOwner (dpy, cmSnAtom, newCmSnOwner, wmSnTimestamp);

        if (XGetSelectionOwner (dpy, cmSnAtom) != newCmSnOwner)
        {
            compLogMessage (d, "core", CompLogLevelError,
                            "Could not acquire compositing manager "
                            "selection on screen %d display \"%s\"",
                            i, DisplayString (dpy));

            continue;
        }

It waits for metacity to give up the WM_S0 selection before running this bit so I'm not sure what exactly is going on but I'm pretty sure it's on metacity's side.

Any news on this?

Still happening with up-to-date hardy install

Does it work with kwin? If it does, I'll see how they do it.

Kwin 4.0 can replace compiz and compiz can replace Kwin 4.0 when kwin is in compositing mode. Metacity is the odd man out here.

My last comment wasn't completely accurate, the problem is kwin does not look for or set this selection so you can do crazy things like run the kwin compositor at the same time as xcompmgr.

A temporary workaround is not to put metacity into "restart" style in sessions, and instead of "compiz --replace", use "killall metacity; compiz --replace". They must be merged in 1 command because if metacity is killed, it strangely becomes impossible to type at all.

I can confirm that the above work around fixes the problem. Not ideal though.

I can confirm that, this bug is still present in final version of hardy.

HI,

 you may find turning off metacity's compiz module resolves this issue
or at least it did for me.

/apps/metacity/general/compositing_manager set to false in gconf.

 Your results may vary,

  Neal

On Tue, 2008-04-29 at 09:30 +0000, Miłosz Kosobucki wrote:
> I can confirm that, this bug is still present in final version of hardy.
>

In theory it would, because there is no compositor to fight with compiz, but the problem is that it is turned on by default. For users who know what they are doing it won't cause much more pain than 20 mins figuring out the problem, but for less savvy users this is a potential problem.

Thomas: according to the wm-spec and the ICCCM, a composition manager must take ownership of the _NEW_WM_CM_Sx selection, and relinquish it on request to another composition manager. Here are the relevant links:

  * http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2552725

  * http://tronche.com/gui/x/icccm/sec-2.html#s-2.8

AFAIK xcompmgr (which is the source of the metacity compositor, AFAIU) never implemented that spec.

Oh, wonderful. Thanks for finding that. I'll see about implementing it soon (unless Iain does).

Recently Compiz Fusion stopped working on my computer (Ubuntu 8.04 Hardy). Whenever I tried to re-enable it, a message appeared saying that Visual Effects could not be enabled. I discovered the reason was Metacity compositing had somehow been enabled. I definitely did not enable Metacity compositing, therefore I'm wondering whether an update somehow caused this? Should I file this as a separate bug? This should not have happened.

Max, the compositor is enabled by default. So if compiz just segfaulted or got replaced by metacity in any case, it would stay. Tilll you do something about it, that is.

@qinjuehang: Please don't say "the compositor" to mean Compiz, in a Metacity bug about Metacity's compositor. (I assume that's what you mean from context.) It does muddy the waters rather.

@qinjuehang: I'm afraid I don't understand. What would stay? And which compositor? The fact of the matter is, Ubuntu is supposed to allow me to enable Visual Effects through the Appearance config dialog, but it wouldn't until I typed an arcane command in a terminal:

gconftool-2 --type bool --set /apps/metacity/general/compositing_manager false

I shouldn't have to do this. Plus the fact that visual effects were working fine before, and i definitely didn't enable Metacity's compositing manager. So why did this happen? Is it a bug?

@max
By entering

$ gconftool-2 --type bool --set /apps/metacity/general/compositing_manager true

you *activate* metacity's abilities to work as compositing manager. By

$ gconftool-2 --type bool --set /apps/metacity/general/compositing_manager false

you disable this feature again. After you disabled this feature. Compiz should start again.

Chris, thank you for your reply but I think that you misunderstand. I did not ever activate metacity's abilities to work as a compositing manager. It somehow got enabled on its own, possibly after an update installed through the update manager. I therefore had to disable metacity's compositing feature in order to get Compiz to start again.

The point I'm making is I did not ever enable metacity's compositing feature. Therefore how did it suddenly become enabled?

Metacity compositing manager is enabled by default if compiz fails.

With trunk it causes Metacity to crash (it may well have done in earlier situations too, since the session manager sees Metacity going down and brings up another one, so crashes can be invisible). This is not a happy situation. I'm escalating.

Expect some kind of patch by tonight, I hope.

Patch to fix the segfault is committed to upstream trunk, but it still doesn't let Compiz accept the CM selection! I shall continue to investigate, and hope to get more information to you tomorrow.

Here are my thoughts.

Part one, the background reading: It seems to me after a while of digging through the ICCCM that Travis Watkins was incorrect back in December when he said that Metacity was not giving up control of the compositor selection. Section 2.8 of the ICCCM says that anyone who wants a selection can take it. The old owner is told they're losing it, but they don't get a choice in the matter. Obviously it was unhelpful when Metacity crashed at that point, but it no longer does. (Backport to stable is coming soon.)

Part two, the experimentation: I have experimented with the return results around the lines which Travis pointed out. Compiz, as you see, does not check the return result of XSetSelectionOwner. I have checked the result, and it is BadRequest. (In case of strange synchronisation oddities, I have performed the same experiment with an XSync on the previous line, with identical results.) BadRequest is a low-level problem in X itself or in Xlib; I don't know what might be going on here but it would appear to be at least as much a Compiz problem as a Metacity problem, since this error should never appear. I have therefore reopened this bug against Compiz.

I am no expert at this, but the problem seems to be quite simple: xrender_unmanage_screen in src/compositor/compositor-xrender.c always calls meta_screen_unset_cm_selection which calls XSetSelectionOwner with None as the owner. It should only do this when giving up the compositor selection manually (ICCCM 2.3.1), but instead also does it when called by meta_screen_free. By setting the selection owner to None, compiz finds that XGetSelectionOwner does not return the window which it set as the owner and aborts.

Also, the convention compiz uses (set the selection then check it to verify success) seems to be recommended at the bottom of ICCCM 2.1.

Compiz fails to check return code of XSetSelectionOwner which is returning it a low-level X error.

(Sorry, that wasn't a reply to crdlb; I only just got the notification email.)

@crdlb: Your first paragraph sounds like a good solution. I'll try it out this evening and see what I find.

Your second para is entirely correct, of course, but a failure there doesn't necessarily mean that it's the old selection owner's fault if it fails.

This bug was fixed in the package metacity - 1:2.23.34-0ubuntu1

---------------
metacity (1:2.23.34-0ubuntu1) intrepid; urgency=low

  * New upstream release
    - Fix possible compositor crash (LP: #178953)

 -- Pedro Fragoso <email address hidden> Tue, 17 Jun 2008 17:17:05 +0100

I'd just like to point out that this bug isn't really fixed. That crash is only tangentally related to the main bug.

It seems that this could be a real compiz bug, and it still affects Intrepid. Marking the compiz task as confirmed again, so it doesn't fall all the way off the radar.

I confirm this bug, and it's present in intrepid.

If I running metacity and execute this :
gconftool-2 --type bool --set "/apps/metacity/general/compositing_manager" "true"

Ok, I'am running metacity with compositing, but If I try :
System->Preferences->Appearance->Effects Tab and Try to activate any (Normal|Extra|Custom) Effect, the Ubuntu says that if not possible to actvate effects.

Then I run this :
gconftool-2 --type bool --set "/apps/metacity/general/compositing_manager" "false"

Now, I can go System->Preferences->Appearance->Effects Tab and runs any (Normal|Extra|Custom) Effect without errors message.

I can confirm this bug also in Intrepid and the workaround.

I was angry beacuse of this! I'ce searching why compiz wont start and found compiz-check script, what helped me. This bug is really stupid.

I can confirm this in Jaunty.

Results of compiz-check:
Gathering information about your system...

 Distribution: Ubuntu 9.04
 Desktop environment: GNOME
 Graphics chip: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
 Driver in use: intel
 Rendering method: AIGLX

Checking if it's possible to run Compiz on your system...

 Checking for texture_from_pixmap... [ OK ]
 Checking for non power of two support... [ OK ]
 Checking for composite extension... [ OK ]
 Checking for FBConfig... [ OK ]
 Checking for hardware/setup problems... [WARN]

Something potential problematic has been detected with your setup:
 Warning: PCI ID 8086:2a02 detected.

Would you like to know more? (Y/n) Y

 Your particular graphics chip may be blacklisted on certain distributions.
 However that does not necessarily mean you will not be able to run Compiz.

 You can skip this blacklist -- but keep in mind that you did so.
 Do not complain if you encounter any problems with Compiz afterwards.

Do you want to skip blacklist checks by Compiz? (y/N) N

Anyone know of a free as in freedom alternative driver? It worked before. Thanks!

Bobby, to force compiz to run, you should disable the blacklist. It works on my latop, which is also Intel GM965. However, some effects (blur, rain...) don't work, and sometimes your framerates drops really low. Overall its ok though. (I simply commented the blackline in the compiz script, all the way back during gutsy) Also, the intel driver *should* be open-source and free as in freedom AFAIK.

OK, sorry for being so incredibly late about this but hey, better late than never!

I disabled the blacklist and am STILL having problems. I ran compiz from the Terminal, here are the errors:
compiz
Checking for Xgl: not present.
xset q doesn't reveal the location of the log file. Using fallback /var/log/Xorg.0.log
Detected PCI ID for VGA: 00:02.0 0300: 8086:2a02 (rev 0c) (prog-if 00 [VGA controller])
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Checking screen 1Comparing resolution (1280x800) to maximum 3D texture size (4096): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
/usr/bin/compiz.real (cube) - Warn: Failed to load slide: /usr/share/gdm/themes/Human/ubuntu.png

Not sure what this means but it's for the developers.

This bug is still affecting me - ideas?

Thanks!

Bobby: the bug you experience is not the one reported here. Please open a new report, and there somebody will be able to help you. Thanks!

Thanks!
Took your advice, my report bug 363517

I would just like to note that this is still an issue in Karmic with compiz 1:0.8.2-0ubuntu11.

I can confirm it too on karmic
on every reboot, i have to do a compiz --reload

I'd like to be sure we agree on the problem here. If you want to use Compiz, just disable Metacity compositor in GConf (using gconf-editor, under /apps/metacity/general/compositing_manager). If you want to use Metacity, just turn off desktop effects, and then set Metacity as a compositor or not using GConf.

This bug should just git you when you switch from Compiz to composited Metacity, which only occurs when you're playing with window managers. That's annoying when you're performing tests, but in day-to-day use, it should no be a problem.

On Friday 29 May 2009 23:48:57 Milan wrote:
> If you want to use Compiz, just disable Metacity compositor in GConf (using gconf-editor, under /apps/metacity/general/compositing_manager).

I want to use Compiz *AND* Gnome-DO (with composite so it has the Glassy skin).

--
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net && Ubuntu LoCoTeam Portugal http://ubuntu-pt.org
Linux user #443786 GPG key 1024D/A1784EBB

Milan, comment #22 <https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/178953/comments/22> suggests that this is not the case. I found this bug because compiz could not load because of a graphics driver issue. Even when that issue was resolved, compiz still refused to load. It was not until I found this bug that I was able to fix it.

Martey: Yes, the bug will hit you after you returned to Metacity for a short period. In particular, this happens if Compiz cannot start because of a driver problem, because before you fix it you need Metacity to run instead. But what I said is that if you still suffer from this bug, disable the GConf key once for all, and everything will work. And for users that never had their Compiz crashed or blocked, the problem does not appear.

bug still present with intel gma 4500 on Jaunty -- gconf editing field as above fixes it

This bug is also affecting me on Jaunty. Maybe I'm not the norm, but I do need to switch between Metacity and Compiz on a daily basis, so this is quite annoying for me.

The Mac4Lin theme requires awn, which requires compositing. its install had an option to enable compositing in metacity. If I enable compositing in metacity, compiz shuts off, and I can't switch back to it, but I can run awn. If I disable compostiting in metacity, awn disappears, but I can switch to compiz, then run awn again. If I then switch from compiz to metacity -- awn disappears, but I have to reenable compositing in metacity to get it back. If this bug were fixed I wouldn't have to jump through hoops.

As noted on the upstream bug this is actually a metacity problem. The linked branch should fix it though.

This bug was fixed in the package metacity - 1:2.27.0-0ubuntu3

---------------
metacity (1:2.27.0-0ubuntu3) karmic; urgency=low

  * debian/patches/014_fix_wm_cm_selection_timestamp.patch:
    - get timestamp when starting and use it to get and release
      the _NET_WM_CM_SX selection (LP: #178953)

 -- Travis Watkins <email address hidden> Mon, 24 Aug 2009 05:11:47 -0500

I am running metacity version 1:2.27.0-0ubuntu3 and I am still affected by the bug.
When I log in, the gconf setting for /apps/metacity/general/compositing_manager is false, but metacity is running and compiz is not. I had been running compiz flawlessly until a few days ago when it crashed and Desktop effects could not be enabled from System -> Preferences -> Appearance.
I tried restarting the computer and it still didn't work, but I can run compiz --replace and it works flawlessly.

Here is my output of compiz --replace
aaron@truman:~$ killall metacity;compiz --replace &
[1] 4112
aaron@truman:~$ Checking for Xgl: not present.
xset q doesn't reveal the location of the log file. Using fallback /var/log/Xorg.0.log
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Checking screen 1Comparing resolution (1024x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
Starting gtk-window-decorator

That would be bug 420308, not this one.