Hey folks, I also encountered this bug: both gnome3 and acpid were handling powerbutton presses.
A bit of digging showed that the gnome-power-manager has been deprecated and the relevant parts of it have been integrated into gnome-settings-daemon since 3.1.4. This means the current check for gnome-power-manager is no longer sufficient. The attached patch makes acpi-support check if gnome-settings-daemon is running, but only if the installed version is 3.1.4 or newer. This check might be a bit of a hack right now, but I guess the entire "is process X running, then don't handle the key" is in a way. I guess the "perfect" solution would be to connect to gnome-settings-daemon and find out if the "power" and/or "media-keys" plugins are really enabled (like what seems to happen for dcop?). It seems something like this could happen through DBus, but gnome-settings-daemon is only active on the session bus and I doubt it's possible to implement this reliably (since you don't know where the dbus session for the user lives?). Having said that, I guess this patch is a sufficient solution? Gr. Matthijs
--- policy-funcs.orig 2012-01-11 12:50:53.082612087 +0100
+++ policy-funcs 2012-01-11 12:56:18.278874769 +0100
@@ -16,6 +16,15 @@
getXconsole
PMS="/usr/bin/gnome-power-manager /usr/bin/kpowersave /usr/bin/xfce4-power-manager"
PMS="$PMS /usr/bin/guidance-power-manager /usr/lib/dalston/dalston-power-applet"
+
+ # gnome-power-manager is integrated with gnome-settings-daemon (in the
+ # power and media-keys plugins) since 3.1.4, so if we have that version
+ # installed, also check for gnome-settings-daemon.
+ GSD_VERSION="`dpkg-query --showformat='${Version}' --show gnome-settings-daemon 2>/dev/null`"
+ if dpkg --compare-versions "$GSD_VERSION" ge "3.1.4"; then
+ PMS="$PMS /usr/bin/gnome-settings-daemon"
+ fi
+
pidof -x $PMS > /dev/null ||
{ test "$XUSER" != "" &&
pidof dcopserver > /dev/null &&
signature.asc
Description: Digital signature
