http://bugzilla.kernel.org/show_bug.cgi?id=5809
------- Comment #72 from [EMAIL PROTECTED] 2008-05-06 18:57 -------
Hi, Steffen
Thanks for the test.
Sorry for my fault. I mixed the acpidump file on your laptop with another.
But anyway it points the root cause that the initial state of the LID is closed
when using the interface of /proc/acpi/button/LID0/state. It is caused by the
following:
> Method (_LID, 0, NotSerialized)
{
> Return (LIDS) // LIDS is declared in the ACPI_NVS memory and
initial value is zero.
> }
When the LID button is pressed, the _Q5E/_Q5F object will be executed and the
state of the LID can be updated correctly.
> Store (LIDS, \LIDS)
> Notify (LID0, 0x80)
And if the LID state is stored to the global variable \LIDS in the custom
DSDT, we will get the correct LID state using /proc/acpi/button/LID0/state.
> Method (_REG, 2, NotSerialized) {
> If (LAnd (LEqual (Arg0, 0x03), LEqual (Arg1, One)))
> {
> Store(LIDS, \LIDS)
b. takes 12 seconds to receive the LID event when the LID is pressed
According to the test on Windows it seems that it also takes about 12
seconds before the notebook starts to enter suspend mode after closing the LID.
IMO this is related with the BIOS. Maybe the delay is a feature of this laptop.
Since the two above issuse are caused by BIOS and can't be fixed in Linux
ACPI, IMO this bug can be closed.
Thanks.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
