compiz-fusion does not start on login

Bug #130450 reported by Thomas Wolfe
18
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Fix Released
High
Unassigned

Bug Description

Binary package hint: compiz

in gutsy, in appearance, I select normal effects, and it works great. I save my session, log out, log back in, and I have no window manager running at all, I have to open appearance again (it still shows up as normal selected) and select none and again normal for it to work... very annoying. Using and ati card with open drivers.

Related branches

Revision history for this message
Michael Vogt (mvo) wrote :

Thanks for your bugreport.

Can you please attach the file "~/.xsession-errros" after a login with the described failure?

Thanks,
 Michael

Changed in compiz:
status: New → Incomplete
Revision history for this message
Thomas Wolfe (tomwolfe) wrote :

interesting
/usr/bin/compiz.real (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
/usr/bin/compiz.real (core) - Error: Failed to manage screen: 0
/usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0

but it works when I go to the appearance applet and go back to none and then to normal...

Revision history for this message
Matteo Settenvini (tchernobog) wrote :

I'm seeing the very same thing as Wolfe in my .xsession-errors, but I have an intel card (an Intel Corporation 82852/855GM).
The strange thing is, if I launch compiz by going to the gnome-appearance-properties again and then selecting "Normal effects", I read in a console this output:

No nvidia hardware available
Checking for Xgl: not present.
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 for nVidia: not present.
Checking for Xgl: not present.

So GLX_EXT_texture_from pixmap should be there at least for indirect rendering?
See also my glxinfo output (attached).

Revision history for this message
Daniel Harvey (daniel.harvey) wrote :

I have the same problem running Gutsy Tribe 5.

My ~/xsession-errors attached; compiz related entries are:

grep -i compiz .xsession-errors
/usr/bin/compiz.real (core) - Fatal: GLX_EXT_texture_from_pixmap is missing
/usr/bin/compiz.real (core) - Error: Failed to manage screen: 0
/usr/bin/compiz.real (core) - Fatal: No manageable screens found on display :0.0
(compiz-tray-icon:23646): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(compiz-tray-icon:23646): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
(compiz-tray-icon:23646): GLib-GObject-WARNING **: invalid (NULL) pointer instance
(compiz-tray-icon:23646): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
(gnome-compiz-preferences:24022): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path: assertion `g_path_is_absolute (local_full_path)' failed
** (gnome-compiz-preferences:24022): WARNING **: plugin inputzoom isn't installed

Revision history for this message
Travis Watkins (amaranth) wrote :

This problem is not fixable. The session saves 'compiz.real' instead of 'compiz' you the proper environment to run compiz.real is not saved.

Changed in compiz:
status: Incomplete → Won't Fix
Revision history for this message
Travis Watkins (amaranth) wrote :

s/you/so/

Revision history for this message
Daniel Harvey (daniel.harvey) wrote :

Not fixable? I don't understand - I'm happy *personally* to run compiz each time I log in.

BUT, as usability a issue it seems to be unacceptable that a user running compiz does not get a window manager when they log in. This can be a major pain - for example, when I log in the windows (without the window manager) obscure the top gnome panel and applications menu, making it quite painful to get to a terminal to start compiz etc. This is not satisfactory for an everyday user.

Am I missing something (happy if I am...)?

Revision history for this message
Thomas Wolfe (tomwolfe) wrote :

I think Travis just needs to double check his grammer (I think that is what the s/you/so/ is about, but many people [myself included] don't understand that). Question is, why is the session saving compiz.real instead of compiz, and why is it that that cannot be fixed (it is a technical problem, of course it can be fixed, now social problems are almost impossible to fix).
(you the proper environment to run compiz.real is not saved. does not make any sense to me).

Revision history for this message
Matteo Settenvini (tchernobog) wrote :

So how about adding a .desktop file in ~/.config/autostart calling "compiz --replace" if the user selected "normal/extra effects" in the relative appearance settings tab?
Obviously selecting "no effects" should delete/disable it.

Revision history for this message
Travis Watkins (amaranth) wrote :

The problem is that you need LIBGL_ALWAYS_INDIRECT defined to run compiz but when you do a session save/restore it saves the real compiz program instead of our wrapper script that sets up the environment so compiz can run. gnome-session isn't doing anything wrong, compiz isn't doing anything wrong, it's the combination of the two plus the oddities of Xorg/driver design that make this situation broken. There might be a fix, someday, but it'll be a major change in the way drivers and/or GLX work.

Revision history for this message
Thomas Wolfe (tomwolfe) wrote :

I agree, to properly fix the problem it will probably require a good deal of work (I don't know, but I am assuming, I would have to know more about the whole indirect thing, is it a driver problem that things have to be done indirectly, or hardware?). But for now, could a simple patch against gnome-session work (possibly for gutsy+1, not sure if you want to add something like that that might fix one problem and create another especially since we are nearing beta) so that it won't save compiz.real (while saving running processes, check if the process it is saving is compiz.real and if it is save it as compiz instead, I don't really know how gnome-session works, but I imagine it does something similar)? Yes, it would be an ugly hack, but it would make it a much nicer experience for users ("ah, why the hell is this not working, I give up" users are not going to google something like this, it should just work, they don't care if you have to use ugly hacks to make it work, so long as it works) and could be easily dropped once it was properly fixed (something that could take years to finish). And I think that would be the easiest way, if you wanted to fix it via compiz, the only way I can really see at the moment is to merge the compiz wrapper script with compiz itself, which is not really a good idea. Thanks for explaing that though Travis, although why mark this as won't fix if it is a problem and it does affect users. I understand it will take a lot of time and effort (I think) for fixing a very small problem, but it should not just be overlooked. Ignoring a problem does not make it go away.

Changed in compiz:
importance: Undecided → Low
status: Won't Fix → Confirmed
Revision history for this message
Jose De la Rosa (jose-de-la-rosa) wrote :

I've seen this issue on 3 different systems with Gutsy Tribe-5, with Intel and nVidia graphic cards. My .xsession-errors file shows the same messages as indicated here. Happens after I save my session and then restart GDM.

Not an issue when desktops affects are turned off.

Changed in dell:
importance: Undecided → Medium
Revision history for this message
Jose De la Rosa (jose-de-la-rosa) wrote :

Worth noting:

- After logging in (after entering password) system takes 2-3 minutes for X session to start.
- Running "compiz --replace" is the workaround I've used.

Also, the comment above should read "desktop effects", not "desktop affects".

Changed in dell:
importance: Medium → High
Changed in dell:
status: New → Confirmed
Changed in compiz:
status: Confirmed → Fix Committed
Revision history for this message
mannheim (kronheim) wrote :

Supposing that the wrapper is called "compiz" and the binary is called "compiz.real", then this can be fixed be ensuring that the wrapper script ends with something like

 exec -a compiz compiz.real $OPTIONS ...

This will exec the binary compiz.real, but compiz.real will run with its progname set to "compiz". That way, the session code in compiz.real will be fooled into telling the session manager to relaunch "compiz" (the wrapper) instead of "compiz.real" (the binary).

Revision history for this message
Travis Watkins (amaranth) wrote :

Unfortunately that only works in bash, not dash (which we use).

Revision history for this message
mannheim (kronheim) wrote :

I didn't realize it was a bash-ism. Is it not allowed to begin the script with #!/bin/bash ?

Revision history for this message
Matteo Settenvini (tchernobog) wrote :

@mannheim: it isn't recommended for two reasons:
a) the user could use another shell that is not bash
b) there's no guarantee that bash isn't installed elsewhere in the path (for example, /usr/bin/bash)

Instead /bin/sh is always there and usually a symlink to the current shell.

Cheers, matteo

Revision history for this message
Travis Watkins (amaranth) wrote :

We don't have to care about if the user is using bash or where it is. We can guarantee it's installed and use it directly and we know where our package puts it.

Changed in compiz:
importance: Low → High
status: Fix Committed → In Progress
Revision history for this message
Michael Vogt (mvo) wrote :

compiz (1:0.5.2+git20070917-0ubuntu1) gutsy; urgency=low

  * new 0.6 branch snapshot
  * new ABI version
  * debian/compiz.wrapper:
    - blacklist the "mga" driver (LP: #122961)
  * debian/patches/022_fix_session_managment.patch:
    - fix the session managment id (thanks to Keybuk, LP: #130450)
  * debian/patches/023_ignore_hints_when_maximized.patch:
    - honor the maximize hint

 -- Michael Vogt <email address hidden> Mon, 17 Sep 2007 14:26:17 +0100

Changed in compiz:
status: In Progress → Fix Released
Revision history for this message
Jose De la Rosa (jose-de-la-rosa) wrote :

Worked for me with latest updates.

Changed in dell:
status: Confirmed → Fix Released
Changed in somerville:
importance: Undecided → High
status: New → Fix Released
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305760

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.