ACPI on Dell 8600
 

How can I get ACPI working on my dell 8600? I'm using Slackware 10.1 and kernel 2.6.10. All the ACPI stuff is compiled as modules in the kernel.

What do I do now? I really want it to go into standby when I close the laptop screen.

(It is my understanding that ACPI must be compiled in the kernel and cannot be loaded as a module, as the previous APM could.)
If you are not compiling your own kernel then choose the bareacpi kernel

you can find it on disk 1 in <cdrom>/kernels/bareacpi.i/

copy the contents to /boot and setup your bootloader appropriately.

If after booting your new kernel the ACPI does not work (mostly old laptops/BIOS ... like mine) you can pass the kernel parameter "acpi=force" at boot. You can do this manually or configure your bootloader to do it.

The bareacpi.i kernel is only 2.4. I upgraded to 2.6.

So if I compile all the ACPI stuff into the kernel, instead of having them as modules, it will just work? I don't have to do anything else?

Ok. I recompiled the kernel. Now when I start kde it has the little battery icon in the taskbar so it is working.

But if I go into KDE Control Center > Power Control > Laptop Battery and Enable Stanbdy in the ACPI Config tab and then right click on the battery icon in the taskbar and select standby, the screen will just go black for like a second before coming back. What;s wrong?

I'm in the same boat. Anybody know what's wrong?

I can't get power button & lid close working on a Dell 5150. Now I'm googling for patched DSDT, but until now I didn't find anything.

Nobody knows? That makes me sad...

Me too. :(

I remember seeing this post last week when it first got created, and I have the same laptop, thought it'd help me get ACPI figured out. :o

I could never get ACPI working on my 4100. Hell, I couldn't even get the battery monitor to display. So I've used APM forever. Keep this thread in mind if anyone ever figures it out.

Hi,
I dunno if this will work for you, but I have recently found a solution for my laptop. After a couple of weeks of struggling with getting acpi to work on my IBM thinkpad R40, finally found this:
acpitool
Tried the slack package, but that didn't work, so I just compiled from source, rewrote the relevant event file in /etc/acpi/events to run acpitool -s (to suspend) when I close the lid or hit a special fn key combo (requires extra kernel support - so probably won't work on a Dell) and voila, it works!

for example I have a file called /etc/acpi/events/lid.conf that looks like so:
to find out what acpi calls events look at /var/log/acipd

In case I screw things up there is another file called /etc/acpi/events/powerbutton.conf that enables me to shutdown gracefully with the powerbutton

Hope that helps,
-geomatt

Running acpitool -s makes the following message flash, and then it returns to the command prompt:
lspci returns this:

i have a dell 4150, and when i was compiling a custom 2.6.10 kernel a few weeks ago i noticed a kernel config option called suspend, which was listed as experimental. therefore i chose not to include it. is it possible that you need that option compiled into the kernel in order to make suspend work?

Pig Monkey,
What does it say in /var/log/acpid?


mcd,
That's suspend to disk or software suspend: s 4 (acpitool -S) as opposed to suspend to RAM: s 3 (acpitool -s). It's only the suspend to disk (that writes an image to the swap partition) that is experimental. Without it you should still be able to suspend to RAM.

-geomatt

I'm not sure what I did, but after lots of tinkering any many reboots, ACPI appears to be halfway working. Now, when I do acpitool -s, it appears to suspend correctly: the screen goes black, the power LED fades in and out. The trouble is, it won't come back. If I hit the power button, it sounds like it's powering up, the power LED becomes constant, and the screen lightens a bit, but nothing else happens. I have to hold down the power button to shutdown.

/var/log/acpid is long, so I uploaded it:
http://pig-monkey.com/nix/acpid

OK. Looks like you have one script that is being invoked by acpi called /etc/acpi/acpi_handler.sh. The way the system works is that when an event happens an action is triggered.
In your case the event is this:
which is this passed to the script in the /etc/acpi directory. So the thing to do would be to mess around with that script or just tweak the rules in /etc/acpi to do what you want without it. I think the acpi_handler.sh script is just a default that doesn't do much. My rules don't invoke that, they are much simpler and just call acpitool directly.
the "button/lid.*" is just short for the full event name.

Oh, and for acpitool -s to work properly I think you need two of the same events to happen sucessively. So close the lid and reopen it, or once you set up a rule that calls it, press the little lid closing button once, wait and then press it again. The power button is a different event.

Cheers,
geomatt

I changed /etc/acpi/events/default to what you said. I press the lid button and it works, but if I press it again, it still won't come back.

Oh sorry - forgot to mention - did you stop and then restart the acpid process? No need to reboot. Just ps -ef | grep acpid then (as root) kill xxxx (whatever # it has) and then start it up again by typing acpid. When the rules are changed it needs to be stopped and restarted.

If you did that and still had the problem, maybe you could see if the event of the second button press is even registering by disabling the scripts and running tail -f /var/log/acipd and watching the output as you press the button....

Hope this helps,
geomatt

Yeah, I restarted it.

And yup, it is seeing the second button push.

Sheeeeet. I dunno. Hmmm maybe take a look at what acpitool -w tells you. It should list wake-up capable devices. If the lid is not there try enabling it with acpitool -W x where x is the number of the lid as revealed by acpitool -w


-geomatt

It says enabled next to lid. Like I said, when I press the button again it does sound like it's powering up, the power LED becomes constant, and the screen lightens a bit, but nothing else happens. So it sees the event and is trying to do something about it...but fails.

Dag! I wonder if the support for your laptop isn't quite there yet...

Just checked at ACPI4linux and they have a bug report about the lid not working on the Dell 5150 for kernel 2.6.10

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

-geomatt

That bug is for the 5150 and the description is "Button and lid events do not work at all. The event is not getting transmitted. Using acpid does nothing."
I'm on the 8600, and I'm getting a bit further than that. At least the lid button does something.

This one seems a bit closer to home: http://bugzilla.kernel.org/show_bug.cgi?id=3203
But it still doesn't help me solve anything...

I wonder how long it will take to get 2.6.11 into slackware-current/testing/packages/

Oh, my bad.
About 2.6.11 - I saw on slashdot that it is out as of today. Here it is. You can just download the source and then compile it yourself. No need to wait for Patrick - just use your old .config as the basis for recompiling. I've just spent the last two weeks fiddling around with kernel compiling and such trying to get acpi working and other things fixed.... Tons o' fun.

-geomatt

Just glancing through, there seems to be a lot of changes in the 2.6.11 kernel with ACPI. Anyone tried the new kernel yet to see if it works on their dell?

EDIT:
I just found this in the change log--may be related??

In fact, going through it, it seems like there have been a few changes directly related to dell laptops (alps touchpad drivers, ac97 fixes for dell quirks {whatever they are } and so on). I think I'm going to try updating the kernel just for the heck of it. Wish me luck!

That looks promising.

I've never used an old config before when updating the kernel. Do I just copy the config file into the new kernel source directory and then do my make menuconfig etc...?

Yup. Your current configuration will be there along with new options.
I keep copies of my config files stored away someplace safe. And then copy them into the kernel source tree as needed. Saves eons of rooting through kernel options.

-geo

well, the 2.6.11 kernel boots up great. It feels to me like it boots up a little quicker, and I think I even fixed my sound problem, but I can't get the nvidia drivers installed for some reason. Looking for help there in a new post, if anyone has any ideas. Shutting the lid doesn't do anything right now, so I need to fiddle with it a bit more. It'll help to get x up again first. Anyone else in the middle of trying this?

Quick Update:
I got the kernel patched up so the graphics drivers work. I don't have acpi working at all yet, but I did notice at http://acpi.sourceforge.net/download.html there are some patches for 2.6.10 and 2.6.11-rc4. Anyone know what these are for?

I finally updated to 2.6.11. By the time I got around to it, the new kernel was already in slackware-current, so I just used those packages.

No change with ACPI. :(

5150 Lid Button
 

A friend has a 5150 with the same problem so I wrote a little script to fix it.

--------------------------------------------------------------CUT-------------------------------------------------------------

#!/bin/bash
#-----=( Notbook Lid Switch )=---------------------------------------------
#
# what: notebook/laptop lid switch detector
# who : theBleeber --=( me [at] bleeber [dot] com )=--
# why : this script is meant to turn off your lcd when the lid is shut.
# if this works for you already, great. if not, use this.
#
#----------------------------------------------=( linux.bleeber.com )=-----

LIDBTN='/proc/acpi/button/lid/LID/state'
BTNST=`awk '{print $2}' $LIDBTN`

# echo $BTNST

while true
do
if [ $BTNST == "open" ]
then `xset dpms force on`
else `xset dpms force off`
fi
sleep 5
done

--------------------------------------------------------------CUT-------------------------------------------------------------

just copy this text into a empty file.
copy the file to /etc/rc.d/
chmod the file 755
reboot.. then you button will work

Well, that script didn't work for me. It didn't change anything, so I just removed it. I did notice, though, that in /proc/acpi/button/lid/LID/state, it does change automatically when I press the lid button. eg. When I don't press it, the file says it is up, and when I hold it with my finger, the file says it is down. Going through dmesg, I found these lines:

Is i8kutils just out of date enough that it doesn't really support the 8600? Another possibility is just that the events handler for ACPI isn't configured right, but I haven't figured out yet how to change it. (If I try and read /proc/acpi/events, it just tells me it's being used and can't be read.)


Keep on plugging away, I guess. Too bad I have so much homework I'm supposed to be doing instead...

blueCow: does this script work if acpid is running?

That just uses DPMS to turn off the screen? Would it work if there is no X running?

I'll try it in a bit...

Well, that script seems to work great as long as X is running. My only complaint (beyond it requiring X) is that when I open the lid, I can no longer click with the track pad -- I have to use the buttons.

Edit-
Another problem: the script only works once! I can hit the lid button as many times as I want and nothing happens. /proc/acpi/button/lid/LID/state still reads the status correctly.

@Pig Monkey: How do you start the script?
Try starting it with ./script &

instead of just
./script

I'm not starting it at all. I moved it into /etc/rc.d
Doesn't that load it automatically?

nope. make sure you added execute permission (chmod +x /etc/rc.d/rc.myscript) first. then decide where you want to call it. i suppose a fairly safe place would be rc.local, but other ppl probably have more suggestions. so anyway, open up rc.local and add a line starting your script:

/etc/rc.d/rc.myscript start

and *then* it will load automatically at boot.

Ok, I did that. At first it couldn't find xset (not in root's path, I guess), but I changed it to the full location in the script (/usr/X11R6/bin/xset) and fixed that problem. Now the script appears to run but do nothing. Whether it launches through rc.local or I launch it myself (both as user and root), nothing happens. It returns no errors, but hitting the lid button does nothing.

Before I still had the power management enabled in KDE's control center, which is why I saw it doing something. Strangely, that seemed to work better than it ever had before (it actually went to sleep and woke back up, only with the previously mentioned problems of only working once and not being able to click with the trackpad) and I'm not sure what I've done to cause that.

Everything is commented out in /etc/acpi/events/default and when testing the script I disabled everything in KDE's power control.

Yes you are right. This script will only work when X is running. I am currently looking for a way to fix that.. It would have to be completely different though, seeing as the only thing I am really doing is monitoring the state and running the x command to turn off the display.

This script will work with acpid running and I believe it has to have acpid running to work.

Glad it helped out some of you.