I'm wrestling with the common problem of the lid button crashing my computer. I've spent quite a while googling and tinkering, and presently I'm left at a position where the answer seems to lie beneath the surface so I'm looking for any help before I fully immerse myself and sacrifice the rest of my life for a minor annoyance.

In my present approach I'm trying to isolate some of the potential issues; presently it still freezes solid (unresponsive keyboard (including lights) and stuck cursor on black screen) in X, but I've gotten it to work in a console vt (with or without X running). I'm using vbetool in my acpi scripts at the moment for a lower level access to the monitor which should work for both interfaces, but X (xorg 1.3.0) seems to be handling the lid button signal and locking up before the acpi script is touched. So for now I just want to make sure that X isn't doing anything in response to the lid button event...any ideas?

I have a Dell Inspiron 1100 and Inspiron 1150 both running Ubuntu Hardy.
On the 1100, closing the lid blanks the screen and it does not return when the lid is reopened. [Ctrl][Alt][Del] & [Alt]+S shuts down the computer. On the 1150, closing the lid puts it into some unknown state with a blank screen (I do not have the skills yet to determine what) I have to physically power down to restart.

I have disabled lid.sh which executes on the 1100 and not on the 1150. No apparent effect there. Power Manager is set to do nothing on both machines. Something upstream appears to be causing problems.

Likewise, I would appreciate any help available.

My issue was caused by the "intel" video driver and was resolved (though other issues appeared) when I downgraded to the i810 driver (v1.7.4). The two drivers are apparently fairly different and I find it a bit disappointing that they were so seemingly prematurely merged together in portage. The newer intel driver appears to operate properly when both pipes are active (an external monitor is connected), and there is a kludge that should manipulate that which doesn't seem to be any different "ForceEnablePipeA" or something. Some other cards seem to suffer a similar problem and there are numerous threads. Presently I'm playing the waiting game until the issue is resolved or I have more time to play with it.

If your case is different, check to see whether your computer is frozen or the screen is just stuck off (Ctrl+Alt+Del would imply the latter). If it isn't frozen then also look into the X DPMS settings and any potential xauthority settings (the ACPI messages won't be coming from the user).

Here's a good thread to start with:
https://bugs.launchpad.net/debian/+s...el/+bug/138256

All of the ACPI actions trigger "events" which are initially handled by the kernel, then passed to a user-side daemon. (A "daemon" is what Windows would call a "service").

When the lid is closed, as when the lid is opened, certain things can occur. For example, when the lid is closed, video should be turned off and maybe a suspend-to-disk should be started. When the lid is reopened, video must be turned back on.

Unfortunately, "not all laptops are created equal." They don't all use the same video hardware. While they do contain a machine-readable description of what hardware they do contain (so that Linux can be, and does try to be, "smart about it..."), there can still be ... "issues." The standard reaction to lid-open or lid-close might not be appropriate for your hardware, and might in fact cause grief.

If you're using a stock distro, you're probably not the first person running hardware "just like yours" who has encountered whatever you are seeing. There probably is a package available to fix it.

If you're running Gentoo ... look in /etc/acpi ...

This is just one of those things that you learn to expect in the Linux world: manufacturers set-up their computers to run Windows, and they tweak the software just-so. When you install Linux (or for that matter, when you install a non-OEM copy of Windows!), you can encounter hardware-specific issues of various kinds. Most are merely-annoying.