ACPI messed up

[Shatter]

Hmm, is anyone else experiencing problems with ACPI on BT4 pre-final? My Compaq NX6610 can't seem to detect when the lid closes and therefore doesn't poweroff the screen. It used to work on BT3 just fine. Seems like the ACPI signals aren't working properly and the lid button doesn't seem to trigger any events.

[warship45]

Yes my dell vostro does the same thing

[pinchegringo]

Did you check the Power Manager to make sure that under the "When Laptop Lid Closed" it isn't at the default setting of "Do Nothing"? Sometimes the obvious gets overlooked, "or so I hear".

[Shatter]

That isn't the problem. Even when I set it to one of the other options it won't do anything. What bothers me is that the acpi_listen doesn't signal any events whenever the lid button is pressed or released and the /proc/acpi/button/lid/C1E1/state always shows closed.

Okay, this is clearly broken in BT4 pre-final and needs fixing! I have a HP Compaq NX6110 laptop, but while performing tests, I have used BT3 final and BT4 fre-final Live CD/DVD images to minimize any modifications that I might have caused by installing BT4pre to HDD. The tests were performed in KDE.

BT3 final: If the lid button is pushed down in BT3f, the screen turns blank and does not power up again until the button is released. This includes moving the mouse, and hitting just about any key on the keyboard... screen stays offline as it should. If you 'cat /proc/acpi/button/lid/C1E1/state' while the screen is on, it shows "open". When you do the same while holding down the lid button, it returns "closed". This eliminates any suspicion that the defect is caused by bad hardware, and we know that the lid button works as it's supposed to.

BT4 pre-final: Broken. The lid button seems to be dead. Pushing and releasing it does not do anything, it does not even signal any ACPI evets in acpi_listen. The lid button status in /proc/acpi/button/lid/C1E1/state is clearly not being reported properly! It always shows "closed" no matter in what state the lid button is - released or pushed down - and as a result, the screen won't go blank. I've used the "xset dpms force off" command to turn off the screen when needed, but sometimes the screen mysteriously turns itself back on (usually one to 5 seconds afterwards) and continues to do so throughout the session. acpi_listen shows a number of events being signalled by god knows what, and I assume they are the reason the screen wakes up. Usually they're most common while battery is being charged. Even when CPU fan speeds up or slows down you get these.

video C054 00000080 00000000
button/lid C1E1 00000080 0000001b
video C054 00000080 00000000
button/lid C1E1 00000080 0000001c
video C054 00000080 00000000
button/lid C1E1 00000080 0000001d
video C054 00000080 00000000
button/lid C1E1 00000080 0000001e
video C054 00000080 00000000
button/lid C1E1 00000080 0000001f
video C054 00000080 00000000
button/lid C1E1 00000080 00000020
video C054 00000080 00000000
button/lid C1E1 00000080 00000021
video C054 00000080 00000000
button/lid C1E1 00000080 00000022
video C054 00000080 00000000
button/lid C1E1 00000080 00000023

I'm guessing this requires some kernel work to fix...

EDIT: Poking around a bit with the power manager revealed that the PC indeed DOES detect the lid close. I've set the option to >blank screen<, and now when the lid button is held down manually the screen powers off. It does not power on again when the button is released tho. Any mouse movement will bring the screen back online regardless whether the button is being held or not. The lid button only works once i.e. after waking up the screen and pushing down the button again nothing happens.