[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#400583: Bug#390929: compiz: "Another window manager is already running on screen: 0"



James Clark wrote:
> I'm getting the same problem with decorations, just like to add my own
> experiences.
>
> Compiz runs fine, with full acceleration. But the decorations refuse
> to load, and gtk-window-decorator starts thrashing 100% CPU time and
> requires a good killing.
>
> I'm running testing/unstable; Here are the versions of relevant packages:
>
> compiz:
> compiz-core:
> compiz-gnome:
> compiz-gtk:
> libdecoration0:
>  Installed: 0.5.0.dfsg-1
>
> xserver-xorg-core:
>  Installed: 2:1.3.0.0.dfsg-6
>
> linux-image-2.6.21-2-amd64:
>  Installed: 2.6.21-5
>
> nvidia-glx:
>  Installed: 100.14.11-1
>
> Yes, I have GLX_EXT_texture_from_pixmap. My xorg.conf has the usual
> requirements. Compiz itself works fine, as it has in the past; it's
> the decorator that's not responding.
>
>
> I thought it could be some conflict with old compiz settings, so I
> tried again with a test user that I blank out. Same results:
>
> rei@yin:~$ compiz --replace
> GLX_EXT_texture_from_pixmap is available with direct rendering.
>
> rei@yin:~$ gtk-window-decorator --replace
> gtk-window-decorator: Could not acquire decoration manager selection
> on screen :0.0
>
>
>
> Finally, I wondered if metacity was somehow interfering, so I logged
> in with a failsafe xterm session. Running compiz works (no need for
> --replace), but gtk-window-decorator still complains.
>
>
> Any ideas? Or should I just wait until the new-fangled compiz-fusion
> arrives in unstable? It's not like I absolutely --must-have-- window
> decorations.


Which metacity are you running? Does 2.18 help?

Brice




Reply to: