Hi all,
Same problem here with a pavilion dm4 1162sf.
acpi_listen give me this :
button/lid LID0 00000080 00000005 -> lid close event
button/lid LID0 00000080 00000006 -> lid open event
button/lid LID0 00000080 00000007 -> lid close event
button/lid LID0 00000080 00000008 -> lid open event
This is incremental, starting by "00000001" on the first close event...
the /proc/acpi/button/lid/*/state stays always "open" so the script will
never catch it as it is today (on other systems like arch linux with
3.1.4-1-ARCH kernel) , the acpi events where clearer with "button/lid
LID open" and "button/lid LID close".
I think all is due to this strange information given in acpi events...
Here are the 2 scripts I used for a workaround on my system (I didn't
edit directly lid.sh as I want it solved without breaking my actual
workaround...) :
cat /etc/acpi/events/lidbtn
# /etc/acpi/events/lidbtn
# Called when the user closes or opens the lid
event=button[ /]lid
action=/etc/acpi/lid2.sh "%e"
cat /etc/acpi/lid2.sh
#!/bin/bash
# TODO: Change the above to /bin/sh
test -f /usr/share/acpi-support/state-funcs || exit 0
. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/policy-funcs
. /etc/default/acpi-support
[ -x /etc/acpi/local/lid.sh.pre ] && /etc/acpi/local/lid.sh.pre
PARAM=$(echo $1 | awk '{print $4}')
PARAM2=$(expr `echo $((0x$PARAM))` % 2)
if [ `CheckPolicy` = 0 ]; then exit; fi
if [ $PARAM2 != 0 ]
then
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"
. /usr/share/acpi-support/screenblank
fi
done
dbus-send --system --print-reply --dest="org.freedesktop.UPower"
/org/freedesktop/UPower org.freedesktop.UPower.Suspend
else
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"
grep -q off-line /proc/acpi/ac_adapter/*/state
if [ $? = 1 ]
then
if pidof xscreensaver > /dev/null; then
su $user -c "xscreensaver-command -unthrottle"
fi
fi
if [ x$RADEON_LIGHT = xtrue ]; then
[ -x /usr/sbin/radeontool ] && radeontool light on
fi
if [ `pidof xscreensaver` ]; then
su $user -c "xscreensaver-command -deactivate"
fi
su $user -c "xset dpms force on"
fi
done
fi
[ -x /etc/acpi/local/lid.sh.post ] && /etc/acpi/local/lid.sh.post
after a reboot, all is ok now....
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-power-manager in Ubuntu.
https://bugs.launchpad.net/bugs/863834
Title:
[regression] Suspend on lid close broken on Oneiric
Status in “gnome-power-manager” package in Ubuntu:
Confirmed
Bug description:
With Oneiric, I cannot have my laptop go into suspend mode by closing the lid
anymore. In the gnome settings, the lid close action is configured to suspend
(both on AC and on battery), but closing the lid does nothing.
Here is the output of "acpid -d" when I close the lid:
No protocol specified
xset: unable to open display ":0"
And here it what it says when I open the lid:
Sessions still open, not unmounting
Here is the output of acpi_listen when I close/open the lid:
button/lid LID0 00000080 00000009
button/lid LID0 00000080 0000000a
Here is what /proc/acpi says with the lid open and closed:
gpothier@tadzim:~$ cat /proc/acpi/button/lid/*/state
state: open
gpothier@tadzim:~$ cat /proc/acpi/button/lid/*/state
state: closed
Suspending in itself works fine with the laptop's suspend button.
Suspend on lid close worked fine in Natty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/863834/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
