[Bug 53042] Re: Avoid acpi button event jitter by having a ignore-event timer
Peping
Peping110 at yahoo.com
Mon Aug 20 20:42:41 UTC 2012
I'm here just to say something quite obvious. The bug also happens when several kinds of invoking the sleep event happen simultaneously, like pressing "Sleep" button and then closing the lid. When you open it, the laptop turns on, then goes to suspend again.
e
It's especially annoying if you change your open/close lid behaviour frequently and don't remember the current setting
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to acpi-support in Ubuntu.
https://bugs.launchpad.net/bugs/53042
Title:
Avoid acpi button event jitter by having a ignore-event timer
Status in “acpi-support” package in Ubuntu:
Confirmed
Bug description:
Binary package hint: acpi-support
The scenario:
The laptop lid is hooked to automatically put the laptop in sleep mode. (sleep.sh is called)
Now, close the lid, but you happened to close it intermittently
(close-open-close quickly) or you have only half-closed the lid.
Laptop goes into sleep mode and powers off nicely. But, when you open
it again, you will notice it will go off into suspend again. This is
because that quick open-close-open generated more than 1 lid close
event and the sleep.sh script is being run multiple times.
The fix:
Keep track of when the last sleep.sh/hibernate.sh was completed, and
ignore if suspend was called again within the last 10 secs or
whatever.. I modified my sleep.sh in the following way, and
hibernate.sh can be done in a similar fashion. Ideally this code
should be somewhere in the backend where you dont repeatedly call
sleep/hibernate multiple times within a given time frame.
--------------- START -------------------------
#!/bin/bash
# Check if sleep occured within the LASTOCCURED number of seconds
# If it did, then exit the script.
LASTOCCUREDSECS=10
# In-progress check
find /tmp/acpiSuspendInProgress &> /dev/null
if [ $? == 0 ]; then
# Already started, exiting...
echo "`date`: acpi: sleep.sh: Already in progress.. exiting" >> /tmp/acpiSuspendLog
exit;
fi
touch /tmp/acpiSuspendInProgress
echo "`date`: acpi: sleep.sh: Starting suspend" >> /tmp/acpiSuspendLog
# Delay check
LAST_RUN=`date --reference=/tmp/acpiSuspendTracker +%s 2> /dev/null`
if [ $? == 0 ]; then
TIME_NOW=`date +%s`
DIFF=$(($TIME_NOW - $LAST_RUN))
if [ $DIFF -le $LASTOCCUREDSECS ]; then
rm -f /tmp/acpiSuspendInProgress
echo "`date`: acpi: sleep.sh: Was called too soon ($DIFF seconds ago), exiting" >> /tmp/acpiSuspendLog
exit;
fi
fi
. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/device-funcs
. /usr/share/acpi-support/policy-funcs
DeviceConfig;
if [ x$ACPI_SLEEP != xtrue ] && [ x$1 != xforce ]; then
exit;
fi
# If gnome-power-manager or klaptopdaemon are running, let them handle policy
if [ x$1 != xforce ] && [ x$1 != xsleep ] && [ `CheckPolicy` = 0 ]; then
exit;
fi
if [ x$LOCK_SCREEN = xtrue ]; then
if pidof xscreensaver > /dev/null; 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
fi
fi
# Generic preparation code
. /etc/acpi/prepare.sh
if [ x$DISABLE_DMA = xtrue ] && [ -b /dev/hda ]; then
hdparm -d 0 /dev/hda
fi
echo -n $ACPI_SLEEP_MODE >/sys/power/state
touch /tmp/acpiSuspendTracker
if [ x$RESET_DRIVE = xtrue ] && [ -b /dev/hda ]; then
hdparm -w /dev/hda
hdparm -C /dev/hda
hdparm -C /dev/hda
hdparm -C /dev/hda
hdparm -d 1 /dev/hda
fi
if [ x$DISABLE_DMA = xtrue ] && [ -b /dev/hda ]; then
hdparm -d 1 /dev/hda
fi
# Generic wakeup code
. /etc/acpi/resume.sh
touch /tmp/acpiSuspendTracker
rm -f /tmp/acpiSuspendInProgress
echo "`date`: acpi: sleep.sh: Completed resume" >> /tmp/acpiSuspendLog
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/53042/+subscriptions
More information about the foundations-bugs
mailing list