My laptop has ACPI running to detect, among other things, the lid state, so that it can shut off the screen if it is closed. However, every once in a while, the functionality simply doesn't work -- I close the lid and the computer doesn't respond. Running /etc/rc.d/acpid restart makes it work again, only to fail again in a few days.

Don't laptops do this in hardware? turning off the screen when the lid is closed? (Mine does so). Whyd would you need acpid to control this? -- damjan

2009/2/9 Leonid Grinberg :

...

Don't laptops do this in hardware? turning off the screen when the lid is closed? (Mine does so). Whyd would you need acpid to control this?

I don't think my laptop does this. If someone has a Dell Inspiron e1505/6400 and knows how to make it turn off the backlight in hardware, please tell me.

I also have the same problem. When I was using GNOME, then it worked fine, but after I switched to xfce then it stopped working, even if I use gnome-power-manager to set it. After that, I installed acpid, add a some scripts to /etc/acpid/events and actions to shutdown the monitor when I close the lid. It didn't work, I am sure that the script work if I run it explicitly, and checking acpid log tell me that the script was executed. After I give up for a few day, it worked again, and after that, it stop working. My laptop is a Dell Vostro 1500.

Well, that's good news, isn't it? :-) At present, I have, in /etc/acpi/handler.sh button/lid) xset dpms force off ;; *) logger "ACPI group/action undefined: $1 / $2" ;; I'll replace with what you have (though xset dpms force off rather than the echo command), and see if the problem goes away. Thanks!

xset needs to connect to the X server, so it needs both for the DISPLAY to be specified and also to have access to the XAuthority cookie for the X server. Otherwise it will not work - can't connect to the X server.

Since acpid runs as a sytem service it ussually doesn't have access to that information.

Hmm, so, so far, everything seems to be working fine... One can play "DISPLAY=:0" before "xset dpms force off", but how does one grant it access to the XAuthority cookie?

So, after a few days of problem-free acpid functionality, it, again, failed to work last night and required a /etc/rc.d/acpid restart, which fixed it. Does anyone know what might cause this? 2009/2/9 Thayer Williams :

On Mon, Feb 9, 2009 at 11:03 AM, Leonid Grinberg wrote:

...

...

xset needs to connect to the X server, so it needs both for the DISPLAY to be specified and also to have access to the XAuthority cookie for the X server. Otherwise it will not work - can't connect to the X server.

Since acpid runs as a sytem service it ussually doesn't have access to that information.

Hmm, so, so far, everything seems to be working fine... One can play "DISPLAY=:0" before "xset dpms force off", but how does one grant it access to the XAuthority cookie?

Can't help you guys much there. I never blank my screen without enabling some sort of screenlock/screensaver. For instance, I use slock which locks the X session and, as a side effect, shuts off the monitor.

On Wed, Feb 18, 2009 at 11:02 AM, Leonid Grinberg wrote:

After many hours of searching, I still cannot figure it out. The problem is definitely not in the xset dpms force off command -- it's in the fact that ACPI simply stops realising that the lid is closed. Is there anything that can be done?

Is it that the backlight stays on after close, or does it stay off and being opened? Have you tried any commands other than xset, such as xscreensaver, etc.? I have the exact same laptop and experience no such behaviour.

OK, the problem is definitely with ACPI -- I just tried it with a completely different app, and it failed as well (while running "xset dpms force off" manually from the command line worked). Might this be an upstream bug?