desktop-packages team mailing list archive

[Sauthess <863834@xxxxxxxxxxxxxxxxxx>]

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