Comment 32 for bug 376793

Update on this bug:
David Tombs reported it to the gnome-power-manager author [1]. It would be best to coordinate fixing of the bug at gnome's bugzilla site. Can someone check out what sounds like a similar bug in Red Hat? They have moved that bug to the kernel (fixed in stock kernel 2.6.32):

"kynde 2009-12-08 04:12:25 EST

This originates to kernel acpi drivers.

The button.c uses what it gets from acpi_device_bid for the
directory name aswell as for the Lid Switch [%s] printk.

The acpi_device_bid is, if I understood correcrly, filled with
what it gets from drivers/acpi/scan.c:
static void acpi_device_get_busid(struct acpi_device *device)

which in turn defaults to calling acpi_get_name from acpica/nsxfname.c.
Now, why that returns C1D0 rather than LID is beyond me.

And about missing events, I think it has to do with
acpi_lid_send_state
 -> acpi_evaluate_integer
     -> acpi_evaluate_object
         and all the "magic" it does there with names

Someone with more knowledge of kernel acpi internals might want to take a look
at this. I'm willing try any patches or produce debugs etc.

I'll compile the kernel with CONFIG_ACPI_DEBUG later tonight when I have access
to said laptop again (it's my wife's, you see) and check if that shows anything
relevant.

Comment 6 kynde 2009-12-09 17:09:55 EST

I've just finished testing with the latest fedora 12 kernel (2.6.31.6-162) and
the problem persist, _but_ I compiled the stock 2.6.32 with the config from
said fedora kernel and low and behold, the lid acpi signaling works.

acpi_listen shows the lid events and system suspended when I configured it to
from power management.

This was about the HP mini 5101 and I have no idea what the situation is with
hp mini 2140 what this bug is about.

Hopefully those acpi changes make it to the fedora kernel soon. I glanced
briefly but didn't spot them in 2.6.31.y yet either."

[1] https://bugzilla.gnome.org/show_bug.cgi?id=607035
[2] https://bugzilla.redhat.com/show_bug.cgi?id=512958