Comment 107 for bug 89860

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.