You are not logged in.

#1 2011-01-22 17:12:37

dvdhrm
Member
From: Germany
Registered: 2011-01-22
Posts: 23

No acpi event when closing lid

I run archlinux on my Samsung N210 notebook and everything works just fine, however,
the kernel does not generate an event when the lid is closed or opened.
Neither `cat /proc/acpi/event` nor `acpi_listen` with acpid running show up anything related to the lid.
I also tried "udevadm monitor" but this also doesn't show any reaction.
I use the intel_agp driver with DRM_I915 and KMS enabled of course.
Since the backlight of the internal monitor is switched off automatically while the lid is closed but no
kernel event is generated, I guess the lid events are still handled in the bios.

Some hints where to start investigating would be helpful wink

Offline

#2 2011-01-22 17:15:23

lagagnon
Member
From: an Island in the Pacific...
Registered: 2009-12-10
Posts: 1,087
Website

Re: No acpi event when closing lid


Philosophy is looking for a black cat in a dark room. Metaphysics is looking for a black cat in a dark room that isn't there. Religion is looking for a black cat in a dark room that isn't there and shouting "I found it!". Science is looking for a black cat in a dark room with a flashlight.

Offline

#3 2011-01-22 17:34:14

dvdhrm
Member
From: Germany
Registered: 2011-01-22
Posts: 23

Re: No acpi event when closing lid

The acpid does not receive any kernel events when the lid is closed so creating any acpid events/actions will not help here.
Moreover "cat /proc/acpi/button/lid/LID0/state" is ALWAYS "state:   open" even if the lid is closed so there seems to be some missing driver setting here.

Offline

#4 2011-01-28 10:51:20

tjbp
Member
Registered: 2010-11-06
Posts: 43

Re: No acpi event when closing lid

I also have an N210, but I'm running Debian Testing on it currently. It doesn't work flawlessly by any means - when I unplug the charger it suspends, and it appears to suspend when opening the lid instead of closing it.

I will try running a script with a loop and log the output of cat /proc/acpi/button/lid/LID0/state later today and post the results.

Offline

#5 2011-01-29 15:04:56

tjbp
Member
Registered: 2010-11-06
Posts: 43

Re: No acpi event when closing lid

I wrote this for the task:

while true; do
    state=$(cat /proc/acpi/button/lid/LID0/state)
    if [ "$state" != "$old_state" ]; then
        echo -en "\a"
    fi
    echo $state
    old_state=$state
    sleep 1
done

and turned off suspend on lid close. Just run the script and it will beep at you when the acpi state changes - it will beep on start up too (so you know if you need to configure a system sound). Otherwise it will print the status to stdout every second.

I find the state is changed to closed approximately 12 seconds after the lid is closed - otherwise it can be reopened and normal operation resumes. I'm assuming there is another event triggering my weird suspend issues. Anyway, I'll put Arch on my N210 soon anyway, so I'll see if I have the same problems with the newer kernel.

For reference this is kernel 2.6.32

Last edited by tjbp (2011-01-29 23:34:19)

Offline

#6 2011-01-29 23:59:07

brianhanna
Member
Registered: 2009-10-30
Posts: 157

Re: No acpi event when closing lid

Are you using pm-utils?

I have a different model notebook but mine doesn't suspend when closing the lid either.  I'm using openbox and pm-utils as it comes "out of the box". 

I just "pm-suspend" when I want it to.  My notebook resumes automatically when I open the lid.  It may be set up this way on purpose to avoid problems on laptops that don't suspend very well.

All that said, I haven't been worried about making it suspend on lid close so I haven't figured out how to do it yet.  I'll try to help out if I get it working.

Offline

#7 2011-01-30 11:49:49

dvdhrm
Member
From: Germany
Registered: 2011-01-22
Posts: 23

Re: No acpi event when closing lid

@tjbp
You're right, the lid-event changes to "closed" approx. 12s after closing the lid. "udevadm monitor" doesn't show any events, though.

I think I will report this to the kernel bugtracker since this seems to be an ACPI bug. Thank you for that hint wink

Offline

Board footer

Powered by FluxBB