[Debian-eeepc-devel] Temporarily disabling lid-close-suspend

Phil Endecott spam_from_debian_eee at chezphil.org
Mon Sep 15 10:01:50 UTC 2008

Hi everyone,

My Eee suspends when the lid is closed, which is normally what I want.  
But occasionally I want to close the lid and not suspend.  I have tried 
to set it up so that I can press one of the soft buttons and lid 
suspend is disabled for a minute.  Here is my attempt:

in hotkey.sh:

         touch /var/run/no_lid_suspend
         { sleep 60; rm /var/run/no_lid_suspend; } &

in lid.sh:

if [ -f /var/run/no_lid_suspend ]
   exit 0

There's just one snag with this: it now suspends when I _open_ the lid! 
(if I've waited for a minute with the lid closed of course).  It seems 
that lid.sh gets run for both lid-close and lid-open events, and the 
call to suspend.sh from lid.sh is not conditional on which it was.

Although this doesn't matter in normal operation (since you'll never 
get a lid-open event if the preceeding lid-close event triggered a 
suspend) I can't imagine that it's what you intended.

For actions other than suspend - for example, screenblank - it would 
make sense to have separate lid-close.sh and lid-open.sh scripts.  
Looking at the output of acpi_listen I see:

button/lid LID 00000080 00000006   <=== lid close
button/lid LID 00000080 00000007   <=== lid open
button/lid LID 00000080 00000008   <=== lid close
button/lid LID 00000080 00000009   <=== lid open
button/lid LID 00000080 0000000a   <=== lid close
button/lid LID 00000080 0000000b   <=== lid open

Hmm.  Does anyone know how I should interpret this?  Is it valid to 
assume that the least significant bit of the last field tells me 
whether it was an open or a close event?  (Is this documented 
somewhere?)  Or maybe there is some other file somewhere to read to 
determine the new state after getting the event.

Regards,  Phil.

More information about the Debian-eeepc-devel mailing list