Re: [gentoo-user] Laptop Lid Close...

[BRM]

Just following up - for anyone searching the archives - the bug report mentioned below did solve the problem.

When I had added the acpid to the default run-level, I had not restarted hald before starting it, thus the script didn't get called.

Any how...it now works excellently. I use radeontool to turn off the screen, and it works without having to know about X.
I also send out a message via D-Bus to the KDE Desktop to initiate the screen saver on close, and turn it off on open. (I ignore the password side of the screen saver, but you can honor that too if you like).

Thanks for the help all!

Ben



----- Original Message ----
From: BRM <bm_witness@×××××.com>
To: gentoo-user@l.g.o
Sent: Monday, January 26, 2009 12:59:55 PM
Subject: Re: [gentoo-user] Laptop Lid Close...

Cool. Thanks. That looks like it should solve the issue.

Ben



----- Original Message ----
From: Gregory SACRE <gregory.sacre@×××××.com>
To: gentoo-user@l.g.o
Sent: Monday, January 26, 2009 11:32:32 AM
Subject: Re: [gentoo-user] Laptop Lid Close...

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=.*
action=/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 <bm_witness@×××××.com> 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 <gregory.sacre@×××××.com>
> To: gentoo-user@l.g.o
> 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="/home/<your_user>/.Xauthority"
> DISPLAY=:0.0
>
> # find out if monitor is on
> STATUS=`cat /proc/acpi/button/lid/LID0/state`
> logger "monitor: $STATUS"
>
> # find out if DPMS is enabled
> DPMS=`xset -display $DISPLAY -q | grep -e 'DPMS is'`
> logger "dpms: $DPMS"
>
> # enable DPMS if disabled
> if [ "$DPMS" == "  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 log
>        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 <your_user> 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 <poisonbl@×××××.com> wrote:
>> On Thu, Jan 22, 2009 at 8:24 PM, BRM <bm_witness@×××××.com> 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 Gentoo 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 'closed'; and I know I could write myself a little script do something like calling radeontool to turn off the backlight, but I'd like to find a more official method.
>>>
>>> I mostly run KDE 3.5 (I'll go to KDE4 when I can...once portage 2.2 comes out and all), but I didn't see anything for a 'turn off monitor on lid close' setting (preferrably root controlled so that it affects all users). The only thing I can find is a the standby/suspend/shutdown/logoff, system performance, and CPU throttling. I don't really want to do any of that - just 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
>>
>>
>
>