From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LRURA-0008SW-L3 for garchives@archives.gentoo.org; Mon, 26 Jan 2009 16:35:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4BEF5E01DB; Mon, 26 Jan 2009 16:35:47 +0000 (UTC) Received: from mail-ew0-f11.google.com (mail-ew0-f11.google.com [209.85.219.11]) by pigeon.gentoo.org (Postfix) with ESMTP id D1B1BE01DB for ; Mon, 26 Jan 2009 16:35:46 +0000 (UTC) Received: by ewy4 with SMTP id 4so1324180ewy.10 for ; Mon, 26 Jan 2009 08:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mxnQRoLXA8ANNYX3OpoSSjofXaW6oFLe5+nlmymJbHI=; b=ojk3MufwGnxQg9JUCuy7bvKeSepEbUzvxnJTKU2rp2SJOByp36A0kQ12AnzWnYVmMF N6HCzLQSeofxEnD35FFj09waxboiAiPzovuPseHmopRuXwZ+RWViaOIs6IZPyNzOeCg8 ZJnxDq8pUHxvpDkpo/Oqp3VgVVusrX5LBONpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=wx4itB1nj3Y/vuDrZ2wpGUde/ZYWT/eKYm37QvAez5Ky/fDrvMKQMN/N1xU+7C3W5N STnHSr5BUwebeAUdxWZnMp8K2ZqQAA7A5ZIf+Cphn4g3wuuFDhKmfi+TdA61N+UijgUZ K7GwRlGdUCGEMKER/+H6q+Qo1Pzj3uY103n0E= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.223.114.74 with SMTP id d10mr765564faq.87.1232987552576; Mon, 26 Jan 2009 08:32:32 -0800 (PST) In-Reply-To: <702343.55891.qm@web65414.mail.ac4.yahoo.com> References: <668013.59864.qm@web65415.mail.ac4.yahoo.com> <5e213dd40901230657s28dec766n108f2352bd2e9e6b@mail.gmail.com> <702343.55891.qm@web65414.mail.ac4.yahoo.com> Date: Mon, 26 Jan 2009 17:32:32 +0100 Message-ID: <5e213dd40901260832m79a03bb7hbd2ff107bed49130@mail.gmail.com> Subject: Re: [gentoo-user] Laptop Lid Close... From: Gregory SACRE To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2de92a32-4410-4dd5-a6ac-60aa84d0a87a X-Archives-Hash: dfddc8a53510226776ba7a3c735ad0e0 I've googled a bit and found these two things: [1] http://bugs.gentoo.org/175464 [2] https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/51591 They both refer to problems with hald and acpid entering in conflict. Check if you are using hald. If you are, try stopping it and starting acpid to see if it still gives you the problem. Concerning the fact that the script isn't called, you have to check in your /etc/acpi/event/default. Make sure that you have lines such as: event=3D.* action=3D/etc/acpi/default.sh %e Basically, it says that for any event handled by acpi, launch /etc/acpi/default.sh. And in /etc/acpi/default.sh, check for the "lid" event. It should look like this: [...] case "$group" in [...] lid) /etc/acpi/screen_off.sh > /tmp/screen_off 2>&1 [...] where screen_off.sh is the script I sent you in my previous mail. HTH, Greg On Sat, Jan 24, 2009 at 4:58 AM, BRM wrote: > For some reason, the script is not getting called when I press the button= . > > That is not to say that the system doesn't recognize it - if I set KDE to= put the system in stand-by when the lid is closed, it very well will. But = as I said earlier, that's not what I want - I just want to turn on/off the = monitor. > > I know kacpid is running...but I don't think acpid is...at least, when I = tried /etc/init.d/acpid start it complained: > > * Starting acpid ... > acpid: can't open /proc/acpi/event: Device or resource busy > > Ben > > > > ----- Original Message ---- > From: Gregory SACRE > To: gentoo-user@lists.gentoo.org > Sent: Friday, January 23, 2009 2:57:31 PM > Subject: Re: [gentoo-user] Laptop Lid Close... > > This is the script I am using. It is spawned by the default.sh from /etc/= acpi: > > -------------------------- SCRIPT START -------------------------- > # default display on current host > export XAUTHORITY=3D"/home//.Xauthority" > DISPLAY=3D:0.0 > > # find out if monitor is on > STATUS=3D`cat /proc/acpi/button/lid/LID0/state` > logger "monitor: $STATUS" > > # find out if DPMS is enabled > DPMS=3D`xset -display $DISPLAY -q | grep -e 'DPMS is'` > logger "dpms: $DPMS" > > # enable DPMS if disabled > if [ "$DPMS" =3D=3D " DPMS is Disabled" ] > then > logger "Enabling DPMS ..." > xset -display $DISPLAY +dpms > fi > > if [ `echo $STATUS | grep -i closed | wc -l` -eq 1 ] > then > logger "[`date`] Turning display OFF" > xset -display $DISPLAY dpms force off > else > logger "[`date`] Turning display ON" # shows up in lo= g > xset -display $DISPLAY dpms force on # turn monitor on > xset -display $DISPLAY s activate # un-blank monitor > fi > > #clean up > unset STATUS > unset DPMS > > # comment this line out if you're manually running this script from a > shell (put a # in front of it) > unset DISPLAY > > exit 0 > -------------------------- SCRIPT STOP -------------------------- > > Change the variable. > I had also to set xscreensaver to switch off my monitor instead of > blanking it, because I think (not sure) that xscreensaver was > switching on my monitor when it was supposed to start the screensaver > (as after a while, my monitor was switched back on, and as I didn't > see that happening since my xscreensaver modification, I can only > assume that was the problem). > > > HTH, > > Greg > > > On Fri, Jan 23, 2009 at 8:14 AM, Joshua Murphy wrote= : >> On Thu, Jan 22, 2009 at 8:24 PM, BRM wrote: >>> I'm running a Dell D600, and I've located a number of tools for it but = I am not seeing anything related to when I close the lid. Since I got Gento= o running on it, the Monitor continues running when I close the lid. >>> >>> I've found several sources for doing something as an ACPI event, which = seems to be the right method. I can toggle the button with the lid open and= cat /etc/acpi/button/lid/LID/state and see it change between 'open' and 'c= losed'; and I know I could write myself a little script do something like c= alling radeontool to turn off the backlight, but I'd like to find a more of= ficial method. >>> >>> I mostly run KDE 3.5 (I'll go to KDE4 when I can...once portage 2.2 com= es out and all), but I didn't see anything for a 'turn off monitor on lid c= lose' setting (preferrably root controlled so that it affects all users). T= he only thing I can find is a the standby/suspend/shutdown/logoff, system p= erformance, and CPU throttling. I don't really want to do any of that - jus= t put the monitor into stand-by, not necessarily the whole system. >>> >>> Any how...I'd really like to get this working. >>> >>> TIA, >>> >>> Ben >> >> In... >> /etc/acpi/default.sh >> >> there's a comment (with commented code you can use following it)... >> # if your laptop doesnt turn on/off the display via hardware >> # switch and instead just generates an acpi event, you can force >> # X to turn off the display via dpms. note you will have to run >> # 'xhost +local:0' so root can access the X DISPLAY. >> >> if radeontool or something will allow you to disable the display even >> when you aren't in X, or without proper access to the display (like >> xset requires) you might be able to even escape needing that xhost >> setting. No way of testing it at all myself though. >> >> -- >> Poison [BLX] >> Joshua M. Murphy >> >> > >