[arch-general] Weird acpid issue
Hello, 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. I am running ACPI 1.2 on 2.6.28. Any ideas? -- Thanks, Leonid Grinberg lgrinberg@gmail.com
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
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. -- Leonid
2009/2/9 Leonid Grinberg <lgrinberg@gmail.com>:
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.
On Sun, Feb 8, 2009 at 1:08 PM, Leonid Grinberg <lgrinberg@gmail.com> wrote:
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.
You're in luck! I maintain the acpid package *and* my notebook is a Dell Inspiron 6400. I use the default handler.sh file for my stuff, found in /etc/acpi. I have the lid closure trigger a suspend-to-ram: button/lid) #echo "LID switched!">/dev/tty5 grep -q closed /proc/acpi/button/lid/*/state if [ $? = 0 ]; then echo -n mem >/sys/power/state fi ;; You can easily replace "echo -n mem >/sys/power/state" with any of the following, depending on your desired result: xset dpms force off xscreensaver-command -lock etc.
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!
I use the default handler.sh file for my stuff, found in /etc/acpi. I have the lid closure trigger a suspend-to-ram:
button/lid) #echo "LID switched!">/dev/tty5 grep -q closed /proc/acpi/button/lid/*/state if [ $? = 0 ]; then echo -n mem >/sys/power/state fi ;;
You can easily replace "echo -n mem >/sys/power/state" with any of the following, depending on your desired result:
xset dpms force off xscreensaver-command -lock etc.
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. -- damjan
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?
On Mon, Feb 9, 2009 at 11:03 AM, Leonid Grinberg <lgrinberg@gmail.com> 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.
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 <thayerw@gmail.com>:
On Mon, Feb 9, 2009 at 11:03 AM, Leonid Grinberg <lgrinberg@gmail.com> 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.
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?
On Wed, Feb 18, 2009 at 11:02 AM, Leonid Grinberg <lgrinberg@gmail.com> 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.
The backlight stays on. I am going to try a different command (a much more visible one); if it gets run correctly each time, then it's xset's fault; else, acpid's. 2009/2/18 Thayer Williams <thayerw@gmail.com>:
On Wed, Feb 18, 2009 at 11:02 AM, Leonid Grinberg <lgrinberg@gmail.com> 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?
participants (4)
-
Damjan Georgievski
-
Leonid Grinberg
-
Phuong Vo
-
Thayer Williams