XGL Stop/start scripts cause hal interface to gpm to fail

Bug #57726 reported by monkeyhelper
6
Affects Status Importance Assigned to Milestone
hal (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I've been running the latest Ubuntu Dapper release with no problems. I recently added the XGL extensions which has caused the suspend functionality to stop working. I've resolved this by stoping the compiz
extension by adding stop/start scripts in /etc/acpi/[suspend|resume].d

stop-compiz.sh
killall compiz.real

start-compiz.sh
#!/bin/bash
getXuser() {
        user=`who| grep -m1 ":$displaynum " | awk '{print $1}'`
        if [ x"$user" = x"" ]; then
                user=`who| grep -m1 ":$displaynum" | awk '{print $1}'`
        fi
        if [ x"$user" != x"" ]; then
                userhome=`getent passwd $user | cut -d: -f6`
                export XAUTHORITY=$userhome/.Xauthority
        else
                export XAUTHORITY=""
        fi
}

for x in /tmp/.X11-unix/*; do
        displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
        getXuser;
        if [ x"$XAUTHORITY" != x"" ]; then
            export DISPLAY=":$displaynum"
            export LIBGL_ALWAYS_INDIRECT=1
            sudo -H -b -u $user /usr/bin/gnome-window-decorator --replace
            sudo -H -b -u $user /usr/bin/compiz --strict-binding
--indirect-rendering --replace gconf
        fi
done

The stop script works fine and I can suspend/resume multiple times with just this in place (I obviously have to start the compiz binary by hand after
resume).

With the start-script in place I can suspend/resume once but subsequent attempts fail, in syslog I see the line :

Aug 21 18:19:23 localhost gnome-power-manager: Suspending computer because the lid has been closed on ac power

Nothing happens after this however. With the two sudo lines commented out,
suspend/resume works multiple times so it's definately one of these actions
that causes the problem.

Attempting to suspend using dbus (after one successful suspend/resume) gives :

dbus-send --system --print-reply --dest=org.freedesktop.Hal \
/org/freedesktop/Hal/devices/computer \
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend \
int32:0

I see :

robl@dexter:~$ dbus-send --system --print-reply --dest=org.freedesktop.Hal
/org/freedesktop/Hal/devices/computer
org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int32:0
Error org.freedesktop.DBus.Error.NoReply: No reply within specified time

Although other dbus-send commands do seem to work (for example activating the screensaver) so dbus doesn't (initially) seem to be at fault.

I initially thought it was a problem with gnome-power-manager but after raising a bug on the gpm bugtacker we determined the problem appeared to be with the hal interface to dbus - see http://bugzilla.gnome.org/show_bug.cgi?id=352283 for more details (please read - it should be very informative).

So it would appear the hal interface becomes unavailable after the initial suspend/resume (this may be related to or looks similar at least to https://launchpad.net/distros/ubuntu/+source/hal/+bug/49442).

I know there are a number of other users with a similar problem and I suspect
with the popularity of the XGL extensions the numbers will grow significantly
so it would be nice to be able to provide a fix.

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

same problem here, after hours of searching on google and the forums, glade I am not the only one.

Revision history for this message
will_in_wi (will-in-wi) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

Revision history for this message
monkeyhelper (robl) wrote :

This isn't an issue in at least Gutsy as the XGL/AIGLX stuff is fully integrated, so from that perspective it can be considered solved.

will_in_wi (will-in-wi)
Changed in hal:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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