broken power button

APM will let me suspend to RAM and restore, but the touchpad is broken the whole time.

So I'm trying ACPI -- ACPI seems to suspend successfully, but it will not wake up. I have to unplug the battery and power supply for 10+ minutes to reset it.

I think it's related to the power button. I notice that the power button does not generate any events via acpid (but if I close the lid, or press Fn-ESC, then I do see events). However, if I hold the power button down for 4 seconds, the machine does shut off immediately. (Holding it down for 4+ seconds while frozen does nothing).

In tracing this further, I noticed that the ASL lists the button 'PWRB', while ACPI (via dmesg) lists the button 'PWRF'. I think (can someone clarify this?) that this is the difference between a "fixed hardware power button" and a "control method power button."

I tried renaming all references to PWRB to PWRF and recompiling, but that did no good. I think (again, can someone clarify this?) that I need to set the PWR_BUTTON flag, but I don't know how to do that. There is a reference to SLP_BUTTON in the dsdt.asl file, but it's in a comment.

Am I on the right track here?

oh, specs: 2.6.2-rc2-mm1 (ACPI v20040116), Dell Lattitude X200 (P3M 800), patched DSDT to cope with battery issue.

Scott

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Apologies for sending this twice, Scott. I forgot to copy the list.

Hi Scott,

I have the same issue with my power button on my Gateway 200X (which
I think is roughly the same machine as the Dell X200). It appears to be an issue with fixed-feature power buttons. I opened bug 1920 to address the problem. You can check it out here:

    http://bugzilla.kernel.org/show_bug.cgi?id=1920

    Thanks,
    Greg

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

the older ones are identical AFAIK; the newer 200X's have 14" screens though and seem totally different.

I applied the patch; I think ACPI should report a warning in this case. According to p63, there are 2 bits of information (4 choices) but only 2 legal possibilities. Windows must be ignoring the PWR_BUTTON field and just checking for the existance of PWRB. ACPI should complain if PWR_BUTTON is not set and PWRB exists, or if PWR_BUTTON is set and PWRB doesn't exist.

Similarly, if SLP_BUTTON is not set and SLPB exists, ACPI should throw a warning too.

Unfortunately, while this lets me receive PWRB notifications, it doesn't solve the lockup on suspend. Ugh.

Scott

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

You're probably right. I am hopeful that we can find a more robust solution to the problem. This is an admittedly sloppy (and hopefully temporary) workaround that just saves me the trouble of commenting out those three whole lines of code in future kernels. :)

Ah, drat. For what it's worth, I have similar issues with suspend, though I haven't tried suspending to RAM for a while, which was when I saw the behavior you describe. I have been able to suspend to disk from a console, and others have reported doing so from unaccelerated X. I've never managed to resume successfully from X, however.

Greg

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn