# Success with ACPI SHUTDOWN

## watersb

FWIW, I played with ACPI again. Shutdown works fine, and might be of actual use to someone.

Suspend is going to take a lot of work, a lot of driver-level development... definitely not something a user can do anything about at the moment.

ACPI IS NOT READY. IF YOU ARE INTERESTED IN ACTUALLY USING IT ON A LAPTOP, MOVE ALONG. NOTHING TO SEE HERE.

Oh, you are still reading this...  :Wink: 

I am using linux-2.4.20-xfs-r2 sources on a Dell Inspiron 8000.

I fixed a problem with the "default.sh" acpid dispatcher script -- it was a trivial thing, but the script that is automatically installed will not decode the ACPI messages on my computer.

The ACPI events look like this:

```

button/power PBTN 00000080 00000001

```

The default script is apparently expecting the initial things like "button/power" to look like "button power" -- that is, it isn't splitting the first param into the subclass.

This is easy to fix, it's just a shell script: add this single line before the case statement in the /etc/acpi/default.sh:

```

IFS="/ "

```

This tells the shell that the '/' and ' '  characters are both item delimiters, so the splitting happens correctly. (IFS is the "input field separator".)

I created a little script that plays an alert sound and shows a "shutdown" dialog box whenever I hit the power button, and the shuts the system down or reboots based on the dialog box input:

```

#!/bin/bash

#

# Maybe shut down the computer, after asking the user for confirmation

#

# Time-stamp: <2003-03-23 19:17:02 bwaters>

#ALERT_SOUND="/home/bwaters/Library/Sound/lcars/Exclamation.wav"

ALERT_SOUND="/home/bwaters/Library/Sound/very-good/shutdown.wav"

DIALOG_MESSAGE=/etc/acpi/user-messages/power

#####################################

play $ALERT_SOUND &

# is X running? if so, try use a pretty dialog, 

#   TODO: (otherwise do something else)

export    DISPLAY=:0.0;

/usr/local/bin/gxmessage --timeout 10 --title "Power Button Pressed" --buttons "Shut Down:16,Reboot:32,Ignore:0" --center --default Ignore --fn '-*-uniread v-bold-r-*-*-10-*-*-*-*-*-*-*' --file $DIALOG_MESSAGE;

CHOICE=$?;

# here's the deal: gmessage should fail with status 1 if it could not

# open the display -- so it will revert to some other thing.

#fi

case "$CHOICE" in

    1)

    /sbin/shutdown -h 1 "[ACPI Power Button] Shutting down in ONE MINUTE, issue /sbin/shutdown -c to cancel!"

    ;;

    16)

    /sbin/shutdown -h now "[ACPI Power Button] Shutting down..."

    ;;

    32)

    /sbin/shutdown now "[ACPI Power Button] Rebooting..."

    ;;

    0)

    logger "[ACPI Power Button] Canceled by User"

    ;;

    *)

    logger "[ACPI Power Button] Unrecognized option"

    logger $CHIOCE

    ;;

esac

```

gxmessage is a little thing that I found at ftp://ftp.owlriver.com//pub/local/ORC/gxmessage/gxmessage-2.0.3-1orc.src.rpm

 -- it's just like xmessage (for which you can read the man page), except it uses GTK2.

I had fun hitting the power button, seeing the little dialog come up, and hearing Majel Barrett's voice telling me that the computer was "initiating shutdown procedures". Whee.

Note that there's nothing to stop you from mapping this to a lid-closing event. So maybe it's marginally useful.

Now: suspend.  One interesting thing I did get to, was that I think I managed to put the nVidia hardward into a real ACPI suspend! This is interesting, because all you mobile OpenGL nuts out there know that nVidia drivers won't suspend with APM normally. But now the nVidia drivers share some code with Windows, and ACPI is in there somewhere...

I did this:

```

% echo 1 > /proc/acpi/sleep

```

... and nothing apparently happened, except that the power LED on the laptop started blinking. While it was blinking, I hit the power button -- and lo! the screen powered down. Now, the hard disk was still spinning, and the network was up, and the power LED was still blinking -- that is, everything was still running. No power savings there! But it was interesting that the video subsystem powered down. Another interesting thing is that the button press got trapped -- I didn't hear my power-down alert sound.

"Great, the screen is blanked!" I said, "How do I get it back?"  Well, it's good that I'm such a great typist: I got the screen back by re-booting my machine.

Not ready for prime time. Enough of this, I'm putting APM back in there, and using the XFree nv driver.

(Oh, yeah... I have experimented quite a bit with software suspend in the past, but I don't use it these days because I am concerned about RAM contents that have been written to an unencrypted disk. Anyone could take my computer and find out all kinds of stuff. So I don't use swsusp. But that's just me.)

[/i]

----------

## CodeHacker84

 *watersb wrote:*   

> (Oh, yeah... I have experimented quite a bit with software suspend in the past, but I don't use it these days because I am concerned about RAM contents that have been written to an unencrypted disk. Anyone could take my computer and find out all kinds of stuff. So I don't use swsusp. But that's just me.)

 

You know, that's an interesting point...perhaps that could be implemented.  The only problem is a concern that a hibernate/suspend should take less time to initiate than a hard reboot.  Now, if you chose the correct cryptograpic routine, I'm sure that you could make it work, but the question is how much latency would it add to the restore time.

----------

## Cyclone

Out of curiosity, what is the date of the ACPI are you using in the kernel?  I know development of kernel ACPI is on-going, so bugs are constantly being worked out.  The stable kernel, and even Gentoo's ACPI-sources do not necessarily have the latest patches for ACPI support.

----------

## watersb

 *Cyclone wrote:*   

> Out of curiosity, what is the date of the ACPI are you using in the kernel? 

 

I'm using xfs-sources-r2 for this nonsense... let's see what dmesg says...

```

ACPI: Subsystem revision 20021212

```

----------

