[Bug 57726] XGL Stop/start scripts cause hal interface to gpm to fail

[monkeyhelper]

Public bug reported:

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 at 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.

** Affects: hal (Ubuntu)
     Importance: Untriaged
         Status: Unconfirmed

-- 
XGL Stop/start scripts cause hal interface to gpm to fail
https://launchpad.net/bugs/57726