/proc/acpi/button/lid/*/state always says "open"

[Christian Convey]

My laptop is an HP Pavilion dv4000. I'm running up-to-date Feisty.

Regardless of whether my laptop lid is open or closed, I always get this:

root@peace:/etc/acpi# cat /proc/acpi/button/lid/*/state
state: open

This would explain why I can suspend the laptop using Gnome's power management menu, but why it doesn't do it when I close the lid. (I have specified under power management preferences that it's to suspend when I close the lid.)

I know that at some level the lid switch works because when I press it the screen backlight turns off (although I can still faintly see that the display is still live).

There was one hint of the issue in this email:
   http://lists.opensuse.org/opensuse-mobile/2007-02/msg00016.html

Here's a Ubuntu bug that seems similar, but got rejected:
   https://launchpad.net/ubuntu/+source/kernel-package/+bug/16662

My bug is different than this one:
   https://launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/34389
because my laptop state is *always* reported as open.

I've attached the output of dmesg and dmidecode.

[Christian Convey (christian-convey)]

FYI, I also ran "tail -f /var/log/acpid".

When I do something like unplug the power adapter, I see plenty of output. But when I close or open the laptop lid, I don't see any new output.

[Christian Convey (christian-convey)]

Also, in terms of software versions:

"uname -a": Linux peace 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux

"dpkg -l hal": 0.5.8.1-4ubuntu8

"dpkg -l acpid": 1.0.4-5ubuntu5

"dpkg -l gnome-power-manager": 2.17.92-0ubuntu1

[Christian Convey (christian-convey)]

Note that this present bug is possibly the root cause of the following bug:
https://bugs.launchpad.net/ubuntu/+source/acpid/+bug/48471

[Christian Convey (christian-convey)]

I updated the laptop's BIOS to HP's latest, "F.17" and the bug is still manifest.

[Christian Convey (christian-convey)]

But is still present in the updated kernel, version
"2.6.20-11-generic #2 SMP Thu Mar 15 08:03:07 UTC 2007 i686 GNU/Linux"

[Ben Collins (ben-collins)]

I'd still say this is a BIOS bug. Does the laptop lid work under Windows?

[Christian Convey (christian-convey)]

I just tried it just now in Windows, and everything works correctly.

Windows does the right thing when the lid is closed. The screen fully
blanks (rather than just shutting off the back-light) and the laptop
sleeps, which is the action I specified in Control Panel -> Power
Options.

On 3/20/07, Ben Collins <email address hidden> wrote:
> I'd still say this is a BIOS bug. Does the laptop lid work under
> Windows?
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Assignee: (unassigned) => Ben Collins
> Status: Unconfirmed => Needs Info
>
> --
> /proc/acpi/button/lid/*/state always says "open"
> https://launchpad.net/bugs/89860
>

[Christian Convey (christian-convey)]

Fixed!!!

It seems to be fixed with one of today's updates, because I re-confirmed the bug a day or two after updating.

My kernel:
Linux peace 2.6.20-14-lowlatency #2 SMP PREEMPT Mon Apr 2 20:41:03 UTC 2007 i686 GNU/Linux

Actually, I don't think the kernel updated, so perhaps this fix came from some chance outside the kernel itself?

[Christian Convey (christian-convey)]

NOT FIXED!!!

*&^(*&^*% I don't know why, but it's back to the original, bad behavior. I've tried various suspends / hibernates / cold reboots, and I still can't get the /proc/acpi/.../state value to be "CLOSED" when the lid button is down. :(

[Jeff Trull (jetrull)]

This problem appears to be the root cause of my laptop's failure to hibernate on lid close. The settings appear right, and I can see that /etc/acpi/lid.sh is getting run. Adding debug echos to that script shows that /proc/acpi/button/lid/LID/state always gives "state: open".

As with Christian's case, I can successfully hibernate from menus, etc. - just not from lid close. This worked fine on Dapper for me, so seems to be some type of regression.

dmidecode output attached.

Regards,
Jeff Trull

[Christian Convey (christian-convey)]

Fixed in 2.6.22-12-generic (pre-release Gutsy).

Resume-from-suspend still has some issues, like the network interfaces disappear. But the regardless, /proc/acpi/button/lid/LID/state is definitely accurate now.

[Claudio (cwr)]

Still doesn't work on my HP compaq nx5000 and nc6000. Running gutsy and it's 2.6.22-14-generic kernel. Even backlight isn't turned of when closing the lid (or pressing the lid-switch).

[CurtBinder (curt-binder)]

Apparently this sounds like it could be the cause of my HP Compaq nc6320 not suspending on lid close either. I posted a comment about this under https://bugs.launchpad.net/bugs/155502

I probably should have posted here instead.

[Vadim Zeitlin (vz-ubuntu)]

I'm not sure if it's exactly the same bug but the symptoms look similar: under Gutsy, my HP nw8000 never reports lid as being closed in /proc/acpi/button/lid/C138/state and acpid doesn't generate any events when the lid is closed, although it does generate from one up to a dozen of them (!) when it is opened.

Notice that this used to work just fine under Dapper and Feisty so this is definitely a regression. I'd be happy to provide any addition information which may be needed to narrow this down, for now I attach dmidecode output.

[Filippo Pagin (feryllt)]

This bug interests also notebook HP NX6110 (linux certified: http://developer.novell.com/yes/80551.htm) on both ubuntu 7.10 and kubuntu 7.10 (although in different ways).

When I close the lid the screen is correctly turned off. Neverthless when the lid is reopened the system ignores this fact and continue to act as if the lid were still closed.
In kubuntu the screen is turned on for few seconds and then turn off again. The movement of the mouse cause a lighting followed by a sudden turning off.
In ubuntu the screen turn on correctly but programs, like "gnometris", randomly enter in paused mode.
The problem never come with earlier versions. And is really annoying in kubuntu.
(Besides it seems that the system also has problems to enter automatic suspension.)

Refer to:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/159309

[thistleep (ethan1)]

Bug also in effect on HP NC6000. I have three of these notebooks. Two running Gutsy... lid state never changes therefore display doesn't shut off upon closing the lid. The other is running Feisty... lid state changes and display shuts off. Open the lid and display turns on and password prompt appears.

Works in Feisty, busted in Gutsy. Hope this is fixed soon. I like Gutsy a little better than Feisty but cannot live with this bug.

[Fred van Zwieten (kubuntu-dezwietjes)]

Same on HP nx7400 laptop. I'm running the latest BIOS version and it's still there. I've been running openSUSE 10.3 on this machine and it doesn't have this problem, but it did have other sorts of problems in this area, which they fixed with a kernel patch. See https://bugzilla.novell.com/show_bug.cgi?id=326814

[thistleep (ethan1)]

Interesting additional detail...

If I hibernate the laptop (HP NC6000), then "wake" it back up the lid switch status now works as expected. Push the lid button and the status becomes closed and the display turns off. Release the lid button and the status becomes open and the display turns back on again. (I have my lid close action set to display off rather than suspend)

Still not ideal but since my laptop is almost always left on, until a real fix is supplied I can use this work around. Sure wish it would be fixed tho....

Does this work around spark any ideas as to the cause of the problem or better yet a solution???

-e

[massond (davidmasson93)]

I have the same problem, but it won't properly shutdowr as well.

[Fred van Zwieten (fvzwieten)]

I did a upgrade to Hardy Alpha 2 (amd64) no deal. Problem is stil there.

[Fred van Zwieten (fvzwieten)]

I did an install of both ubuntu and kubuntu Gutsy on i386. No deal. Bug is still there.

[david.barbion (david-barbion)]

I have the same problem on a HP NC6000, the state is updated *only* when the sleep button (FN+F3 is pressed and the computer awaken again).
The lid button doesn't affect the state when the computer is on...
Bios 68BDD Ver. F.14

[Jiao Wenmin (hsinjwu)]

Same problem with my HP 520 laptop, version 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux
lid state always open.

[Jiao Wenmin (hsinjwu)]

Lid state reports correctly after hibernate-resume(???)
fine in Winxp

[SUN Gui Lin (guilin-sun)]

I have same problem on my HP 520 laptop.

[kovaje (kovaje)]

HP Compaq nx6310: same problem.

[kovaje (kovaje)]

Under WinXP it has been working fine.
uname -r => 2.6.22-14-generic
Ubuntu Gusty Gibbon 7.10

[drittponken (tosu-michel)]

Doesn't work for me either.

HP compaq nc6000
Ubuntu Gutsy gibbon

[drittponken (tosu-michel)]

Additional info.

As thistleep said before;

He said that if he hibernated his nc6000 and then woke it the lid button works.
That is the case for me too. If works perfectly.

[Mika Fischer (zoop)]

I can confirm this behavior on my Samsung Q45 (https://wiki.ubuntu.com/LaptopTestingTeam/SamsungQ45Dalia).

After boot closing the lid does nothing. After one Suspend-to-RAM and resume cycle, closing the lid works as expected.

I'll attach the dmesg after boot and after the STR-resume cycle...

[Mika Fischer (zoop)]

I forgot to say: I'm running hardy.

Let me know if I can do something to help debugging this problem.

[kovaje (kovaje)]

HP Compaq nx6310
Ubuntu Hardy Heron 8.04

Lid button still does not work.

[Philipp Kohlbecher (xt28)]

I am experiencing the same issue under hardy on a Samsung X20 XVM 1730 V laptop. The lid button state is always reported as "closed", though.

For me, this used to work up until gutsy, I think. It is definitely a regression.

[Arthur Archnix (arthur-archnix)]

I see that the bug has been triaged. I also suffer from the bug. I'm running an up-to-date Gutsy install (uname -r = 2.6.22-14-generic).

cat /proc/acpi/button/lid/C20C/state always returns "open". Closing lid to standby works in vista, so it's not hardware failure.

Unfortunately, dmesg doesn't give any clues. I run dmesg, then close the lid, then open, and nothing new has appeared.

If I can provide more information or run some test please let me know.

[Kostiantyn Kucher (kk222bt)]

I have HP 530 and Kubuntu, and lid doesn't work. I have tried Ubuntu 8.04 as live CD and it works there perfectly, also it does work from Kubuntu 8.04 live CD, BUT after a couple of seconds the display turns on.

[drittponken (tosu-michel)]

It dos work for me now.
I'm running Xubuntu 8.04 Hardy Heron but with the gnome desktop so i guess we can say Ubuntu.

Well i have the HP Compaq nc6000 and the lid works perfekt now :)

[Steve Langasek (vorlon)]

'acpi' is a package that provides an interface emulating an older 'apm' command; please don't assign generic ACPI bugs here.

[Steve Langasek (vorlon)]

acpi-support is also unrelated to the contents of anything under /proc/acpi.

[Philipp Kohlbecher (xt28)]

Here is what happens with a 2.6.30 kernel from kernel.org:

After booting the system, he lid button state is reported as "closed".
After closing the lid for several seconds and opening it again, it is correctly reported as "open".
From that point on, the state is correctly reported, but with a rather long delay (c. 10 seconds).

This behavior probably hasn't changed since 2.6.26 or so.

[Jānis Kangarooo (kangarooo)]

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860/comments/55
This comment reminded me at my bug comment in Bug keyboard freezes on boot--sometimes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190834/comments/13
i could get keyboard working only when pressing to ON right before Ubuntu logo appears and Loading begins
Maybe dublicate source of the problem?

[Mark (mark-ale8)]

I have a HP NC4400 laptop and I'm experiencing the same problem on Karmic Koala (kernel 2.6.31-3-generic). After a cold boot /proc/acpi/button/lid/C241/state always shows "open" no matter if the lid switch is activated. When the lid switch is activated the LCD backlight does turn off but does not trigger the change of ACPI state. Manual sleep from KDE power manager works as expected.

Strangely the workaround posted above corrects my problem. After a cold boot, doing a hibernate manually from KDE power manager and then waking the machine causes the lid switch to start to work correctly.

[hq4ever (hq4ever)]

HP 530 same issue.

uname -a
Linux lucky 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

$ ps -ef | grep acpi
root 18 2 0 19:21 ? 00:00:00 [kacpid]
root 19 2 0 19:21 ? 00:00:00 [kacpi_notify]
root 2213 1 0 19:22 ? 00:00:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket
111 2543 2469 0 19:22 ? 00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
hq4ever 6452 6235 0 21:52 pts/0 00:00:00 grep acpi

[hvh (hvhouten)]

HP compaq NC6320. Same problem.

Also, after 'suspend to disk', the lid state is reported correctly (lshal -m and /proc/acpi/button/lid/*/state and laptop suspends as expected.

uname -a
Linux Pampus 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

[Mark (mark-ale8)]

I recently upgraded to karmic 64bit from 32bit and the problem vanished. Using the stock 64bit kernel the lid switch is working properly, yet did not work in 32bit.

[DeeKey (privateinf)]

Upgraded to karmic 32bit. Does not work on HP Compaq nc600

[DeeKey (privateinf)]

As others noted before after Hibernate the lid started to work.
Unfortunately it is working till first reboot or poweroff.

[AlexW (alex.wedensky)]

HP Pavilion dv4000 -- confirming the issue on both Jaunty and Karmic.

Also, under Karmic:

suspend-->close the lid-->open the lid: laptop wakes up only to go to suspend immediately. Judging by the time stamps from the logs, the suspend sequence continues after waking up. The cycle breaks if wake up is done by pushing the power button. (this is new in Karmic for this machine)

disconnecting the AC sends the laptop into suspend (same in Jaunty and in Karmic).

trying to boot with acpi=off doesn't really fix the issue, but breaks KMS and screen compositing!

guys, please keep working on the solution.

[Jānis Kangarooo (kangarooo)]

lshal -m
and pushing lid button generates 2x times closing and opening.
Start monitoring devicelist:
-------------------------------------------------
12:12:37.511: computer_logicaldev_input_2 property button.state.value = true
12:12:37.527: computer_logicaldev_input_2 condition ButtonPressed = lid
12:12:44.040: computer_logicaldev_input_2 property button.state.value = false
12:12:44.056: computer_logicaldev_input_2 condition ButtonPressed = lid
12:12:51.135: computer_power_supply_battery_BAT0 property battery.voltage.current = 16335 (0x3fcf)

[DeeKey (privateinf)]

Upgraded to lucid (10.04) -- does not work.

Computer: HP compaq NC6000

[Radoslav Kolev (radoslav)]

Same problem on Lucid 10.04 on an HP nc6120.

[MNLipp (mnl)]

Same problem with lucid and nc6000.

lshal -m
and pushing lid button does not produce any output at all (and it is not a hardware failure, checked with Windows).

[MNLipp (mnl)]

Tried lucid with latest 2.6.34 kernel from mainline and the lid button worked again! Couldn't resume from hibernate though. Upgraded to mevarick beta and lid button stopped working again, sigh...

[MNLipp (mnl)]

Being at it, I tried maverick beta with mainline kernel linux-image-2.6.36-999-generic_2.6.36-999.201009240945_i386.deb. This works again (nc6000)! So there's still hope...

[Péter (pepe-ezkell)]

+1 acer travelmate 5520g Linux 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux

cat /proc/acpi/button/lid/LID0/state always says open

[Mikele (mikilion)]

Same problem with Lucid 10.04.1 on HP 530 laptop.
Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 GNU/Linux

"cat /proc/acpi/button/lid/C20C/state" always says open

[Mikele (mikilion)]

I noticed that after it resuming from hibernate the lid button works; if I reboot system the lid button stop working again.

[Mikele (mikilion)]

I found this workaround:
https://bugzilla.redhat.com/show_bug.cgi?id=512958#c23

sudo su
echo 1 > /proc/acpi/video/C085/DOS
echo 0 > /proc/acpi/video/C085/DOS

[DeeKey (privateinf)]

Works for my HP compaq nc6000
Though my command is slightly different:
echo 1 > /proc/acpi/video/C0CF/DOS
echo 0 > /proc/acpi/video/C0CF/DOS

My current system is:
Ubuntu 10.04.2 LTS
2.6.32-28-generic

According to the thread mentioned in previous post the problem could be caused by the patch
"linux-2.6-acpi-video-dos.patch". Not sure if it is present in ubuntu patches.

-----------------------------------------------------
Alexei Panov 2010-03-04 17:42:54 EST

I have found a patch which breaks operation of Lid Switch on HP Mini 5101, and
possible on others HPs.
This patch is linux-2.6-acpi-video-dos.patch. If you build a kernel without
this patch lid switch perfectly works.
I suggest to test for those who have such problem, I have made a variant of a
kernel without the offending patch ftp://ftp.atisserv.ru/kernel-hp-lid/
-----------------------------------------------------

[david.barbion (david-barbion)]

Those 2 commands work for me too on my HP NC6000 (ubuntu 10.10)

[João Gomes (jvpgomes)]

My problem is a little different. I don't know if it is related.

The state in /proc/acpi/button/lid/LID/state is ALWAYS correct.

However, after I close the lid for the first time and open it again, the gnome-power-manager always says:
"lid is closed, so we are ignoring ->NORMAL state changes"
(but the lid is open)

If I reboot or hibernate, everything goes back to the normal. It's only when I close the lid and open it again that this problem appears.

[Giuseppe Stolnicu (giuseppe-stolnicu)]

Bug still present in 11.04 . HP 530 notebook. The only thing that does not seem to work is the lid.

cat /proc/acpi/button/lid/C20C/state
state: open

State is always open, even when I press the little button that should turn off screen (on my HP the screen margins press on a little button above the keyboard when you close the lid) .

In Win 7 it works perfectly, so it's not a hardware problem.

I do not have any "/proc/acpi/video", so I can' test the above stuff.

I have a Intel 945gm express integrated video card - using the i915 video driver.

Can somebody change the status of this bug?

[andrzej (a1-andrzej)]

i confirm that bug still occurs in ubutu 11.04.
There is no /proc/acpi/video/*/DOS, it was there in beta version of 11.04 and "echo 1 >>..." workaround was working like charm.
Now we stuck with no solution...Please help. Maybe other kernel? anything - this is very irritating bug

[BSA (b-s-a)]

Confirm. I have same problem with Gigabyte N601. But LID status is always "closed".
Ubuntu 11.04, x86

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[aysiu (ubuntubugzilla-psychocats)]

This problem still occurs in Ubuntu 11.04. What is the "series" that's not supported? The kernel version? I'm talking about 11.04 with the latest kernel--the problem still exists.

[BSA (b-s-a)]

aysiu, there is new related bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/810602

[adampaetznick (adampaetznick)]

Same problem on Samsung Series 9 NP9003XB running 12.04 (beta 2)

[Terry Hu (hubin-82)]

Hi, I met the same problem. I am on 11.10, upgraded from 11.04. When I close the lid, nothing happened. It affects me very much. Could you please provide the fix? Thanks!

[Wes Garner (wesgarner)]

Unsubscribe

--
Wes Garner
<email address hidden>
Mobile: [phone]
Fax: [phone]
On Apr 2, 2012 11:55 PM, "Robert Collins" <email address hidden> wrote:

> ** No longer affects: acpi (Ubuntu)
>
> ** No longer affects: acpi-support (Ubuntu)
>
> ** Changed in: linux-source-2.6.20 (Ubuntu)
> Assignee: Registry Administrators (registry) => (unassigned)
>
> ** Changed in: linux-source-2.6.22 (Ubuntu)
> Assignee: Registry Administrators (registry) => (unassigned)
>
> ** Changed in: linux (Ubuntu)
> Assignee: Registry Administrators (registry) => (unassigned)
>
> ** No longer affects: acpi
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/89860
>
> Title:
> /proc/acpi/button/lid/*/state always says "open"
>
> Status in “linux” package in Ubuntu:
> Won't Fix
> Status in “linux-source-2.6.20” package in Ubuntu:
> Won't Fix
> Status in “linux-source-2.6.22” package in Ubuntu:
> Won't Fix
>
> Bug description:
> My laptop is an HP Pavilion dv4000. I'm running up-to-date Feisty.
>
> Regardless of whether my laptop lid is open or closed, I always get
> this:
>
> root@peace:/etc/acpi# cat /proc/acpi/button/lid/*/state
> state: open
>
> This would explain why I can suspend the laptop using Gnome's power
> management menu, but why it doesn't do it when I close the lid. (I
> have specified under power management preferences that it's to suspend
> when I close the lid.)
>
> I know that at some level the lid switch works because when I press it
> the screen backlight turns off (although I can still faintly see that
> the display is still live).
>
> There was one hint of the issue in this email:
> http://lists.opensuse.org/opensuse-mobile/2007-02/msg00016.html
>
> Here's a Ubuntu bug that seems similar, but got rejected:
> https://launchpad.net/ubuntu/+source/kernel-package/+bug/16662
>
> My bug is different than this one:
> https://launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/34389
> because my laptop state is *always* reported as open.
>
> I've attached the output of dmesg and dmidecode.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/89860/+subscriptions
>

[knarf (launchpad-ubuntu-f)]

There is a workaround for this bug which has plagued the HP Compaq nc6120 I'm using ever since, well, forever. I was put on the track of this workaround by reading an old Advogato blog entry (http://www.advogato.org/person/mjg59/diary/62.html) where someone by the handle of 'mjg59' tells about his adventures in ACPI-land and the possible use of setpci to get around ACPI table bugs (which I consider this to be). He does not state which register he changed but I found more information elsewhere which implicated register 0xbb. As to which value to poke there I have experimented a bit as this seems to differ between systems. On the nc6120 the following command, when executed after *each* ACPI-event, restores functionality to the lid switch:

sudo setpci -s 00:1f.0 bb.b=04

I attached a tarball containing two ACPI scripts which make that this command is executed after every ACPI event. Using these scripts, my machine works as expected: the display goes black when the lid switch is pressed/the lid is closed. Opening the lid brings the display back to life. Monitoring the state of the lid switch (cat /proc/acpi/button/lid/C1E9/state on this system) shows the reported state to reflect the actual condition, where before it would stay stuck on 'closed'.

So, if you are also bitten by this bug - which has been around for *years* - you might want to try the setpci command I mentioned. If this works (directly or after changing the poked value) you might want to give these ACPI scripts a try. If you had to change the poked value to make it work, you should also change the value in the /etc/acpi/handler.sh script.

[gcc (chris+ubuntu-qwirx)]

I have seen this problem with an Intel Classmate running Ubuntu 10.04 LTS (2.6.32-36 kernel) and also when using a stock kernel (2.6.32.59) which enabled me to do ACPI debugging.

It turns out that the ACPI DSDT table contains a control method _Q2A, which is repeatedly triggered by the embedded controller when automatic brightness control of the backlight is enabled (Fn+F10). This method sends repeated notifications to the kernel to adjust the brightness level, with a delay. These notifications queue up inside the kernel and cause long delays in dispatch of other notifications, such as LID events.

You can see this happening if you build a kernel with the following options:

CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y

and then run the following commands:

/etc/init.d/rsyslog stop
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_layer
echo '0x00000004' | sudo tee /sys/module/acpi/parameters/debug_level
echo -n 'file ec.c +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
sudo egrep '(push query execution|ev_queue_notify_reques)' /proc/kmsg

This will show you 0x2a (_Q2A) events being constantly triggered by the embedded controller:

<7>[ 380.985859] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 380.996304] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[ 380.996331] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[ 381.008269] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[ 381.008295] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8
<7>[ 381.084229] acpi:ACPI: EC: push query execution (0x2a) on queue
<4>[ 381.120283] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x83 (**Device Specific**)
<4>[ 381.120310] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 83) node f70152b8
<4>[ 381.132316] evmisc-0125 [07] ev_queue_notify_reques: Dispatching Notify on [FNBT] Node f70152b8 Value 0x93 (**Device Specific**)
<4>[ 381.132342] evmisc-0201 [07] ev_queue_notify_reques: No notify handler for Notify (FNBT, 93) node f70152b8

Once you press Fn+F7 to stop the automatic brightness control, the Notify queue slowly empties. LID events go to the back of the queue and so they can be executed much later when the queue is full.

It's made worse because the kernel doesn't have a driver for the Notify events (FNBT, 83 and 93) sent by the _Q2A control method, so it doesn't adjust the brightness at all, so next time the EC triggers the _Q2A control method it runs for just as long. If the kernel did adjust the brightness, the next _Q2A would do nothing.

Something similar may be happening in your case and delaying the reception of the LID events that you actually want. You might want to trace all of ACPI instead of just ec.c, since any _E or _L control method could be causing the delay, not just the embedded controller. If you see a long delay between:

<7>...

[taj (othertaj)]

It seems a typical HP problem
For me (NC6320) I check /proc/acpi/video/C083/DOS

I fixed this in 10.04 Lucid, by putting the following lines (both needed, in this order!) into /etc/rc.local

echo 1 > /proc/acpi/video/C083/DOS
echo 0 > /proc/acpi/video/C083/DOS

However, after dist-upgrade to 12.04 this trick does not work anymore...

[adrian (adrianlzt)]

I'm having the same problem using Linux Mint 13 (based on Ubuntu 12.04) with a Compaq nc6000.

Lid state /proc/acpi/button/lid/C139/status is always set to "open", but if I hibernate (pm-hibernate) and wake-up, lid button works correctly.

acpi_listen shows in both cases (with and without hibernating) the lid events:
button/lid C139 00000080 00000048

The last number is increased in each event.
In each event, /etc/acpi/lid.sh is called. This script checks /proc/acpi/button/lid/*/state and acts in consecuence.

[adrian (adrianlzt)]

I've been running the 'fwts --interactive' test before and after hibernate.
The most significant parts:

Before:
Test 2 of 3: Test LID buttons on a single open/close.
Got 25 interrupt(s) on GPE gpe10.
Got 13 interrupt(s) on GPE gpe1D.
Got 38 interrupt(s) on GPE gpe_all.
Got 25 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to closed.
FAILED [HIGH] NoLidState: Test 2, Could not detect lid closed state.
FAILED [HIGH] NoSCIInterrupts: Test 2, Did not detect any SCI interrupts.
FAILED [HIGH] NoGPEInterrupts: Test 2, Did not detect any GPE interrupts.
PASSED: Test 2, Detected ACPI LID events while waiting for LID to open.
PASSED: Test 2, Detected lid open state.

After:
Test 2 of 3: Test LID buttons on a single open/close.
Got 1 interrupt(s) on GPE gpe1D.
Got 1 interrupt(s) on GPE gpe_all.
Got 1 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to closed.
PASSED: Test 2, Detected lid closed state.
Got 1 interrupt(s) on GPE gpe11.
Got 1 interrupt(s) on GPE gpe1D.
Got 2 interrupt(s) on GPE gpe_all.
Got 2 SCI interrupt(s).
PASSED: Test 2, Detected ACPI LID events while waiting for LID to open.
PASSED: Test 2, Detected lid open state.

Complete results are attached.

[juanmanuel (rockerito99)]

For those of you with a Samsung laptop showing this problem, please see this issue:

           https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/971061

in particular my last two posts.

I think a kernel patch can be made to flush the events from the embedded controller, at resume, in the same way that I do it with my C program that I attached to that issue for Samsung laptops (and maybe others with the problem). TL;DR: If the events don't get flushed (queried), the GPE of the EC is never triggered again (chicken and egg situation), my little program queries the events and "unstucks" the EC immediatly.