Local time: 2017-05-01: 3:29:15 AM © Copyright 2003–2013 Darkhorse WinterWolf

winterwolf.co.uk

Dell Power Management

This page describes how to tweak the operation of your Dell laptop's power management facilities to work a little better than normal under Linux. The document has been written based on my experiences with Timon, a Dell Latitude C840 with a P4-M/1800 and 256MB RAM, but most of the suggestions presented here should work well with other Dell laptops, and some would even work well with other non-Dell laptops.

ACPI operation

There are quite a few documents out there on the Internet that describe how to get APM based power management working on a Dell laptop under Linux. I'm more interested in getting ACPI to work, as I quite like the event driven interface that's almost completely customisable. However, with ACPI support as it stands (kernel 2.6.6 at the time of writing), there are a few limitations. Most notably:

Most other things work quite well, though. An ACPI-based Dell Latitude C840 running Linux is certainly a decent system to take on the road.

It's probably worth noting at this point that I would suggest checking if there are any ACPI patches available for the kernel version you're using. If you're still using the 2.4 kernel tree, this is definitely a good idea. Things seem to be kept up-to-date in 2.6, though, but it's still something to consider.

Kernel configuration

The first thing you'll need to do is enable ACPI support in your kernel. I'll assume you have some knowledge of kernel compilation — this is probably a reasonably assumption given that running Linux on a laptop efficiently is not quite as straightforward as trying to run it on a desktop. If you have no experience of this there are plenty of documents out there describing this process, such as the Kernel Rebuild Guide, desgined to replace the old Kernel-HOWTO.

You'll want to set turn off APM support and turn on ACPI support. For your reference, I have the following ACPI components configured:

Component nameConfig tagState
ACPI SupportCONFIG_ACPIBuilt in
Sleep StatesCONFIG_ACPI_SLEEPBuilt in
AC AdapterCONFIG_ACPI_ACBuilt in
BatteryCONFIG_ACPI_BATTERYBuilt in
ButtonCONFIG_ACPI_BUTTONBuilt in
FanCONFIG_ACPI_FANBuilt in
ProcessorCONFIG_ACPI_PROCESSORBuilt in
Thermal ZoneCONFIG_ACPI_THERMALBuilt in
ASUS/Medion Laptop ExtrasCONFIG_ACPI_ASUSDisabled
Toshiba Laptop ExtrasCONFIG_ACPI_TOSHIBADisabled
Debug StatementsCONFIG_ACPI_DEBUGDisabled
Power Management Timer SupportCONFIG_X86_PM_TIMERBuilt in1

1 This is not strictly necessary, I was just trying it at the time. It's up to you. I don't think removing it would cause problems, even with processor speed scaling, but it's something to bear in mind.

All being well you system will next start up and provide the ACPI interface to you. You can check by running something like "dmesg|less" and looking for lines containing "ACPI".

ACPI software support

Just building ACPI support into the kernel will enable CPU idling by ACPI and basic CPU thermal protection, but some events require external handing, such as response to pressing the power button. For this, I'd recommend acpid, which is available in Debian or from the acpid SourceForge site. You could use this to shut down (or software suspend if you get this working satisfactorily), the computer on pressing the power button, for example. All ACPI events should be handlable by acpid, all you have to do is decide what you'd like them to do.

What to do when the power button is pressed is reasonably straightforward. It's also fairly logical that pressing the power button generates an ACPI event that can be handled by the operating system. It might not be entirely as obvious that opening and closing the lid also generated ACPI events. These are very similar to the button events with the added bonus that the current state of the lid (open or closed) can be read. The sleep key (Fn-ESC) also generates ACPI sleep button events that you can progrem responses for.

Lid events

It's interesting to note that unlike other laptops I've seen, when ACPI is enabled on the Dell it won't automatically turn off the backlight when the lid is closed. The result is more power being used and heat being generated than necessary.

I've developed a short script which works around this problem. It currently only works when X is enabled (although just silently exits when X is not running). This script has been set up as the event handler for the lid event. Since the script is set up for my own personal needs, certain assumptions are made. You're welcome to modify the script for your own needs if you'd like to. Currently, the script makes the following assumptions:

This actually works better than the laptop automatically shutting down the backlight when the lid is closed, as when the display goes into DPMS off mode, xscreensaver will not even attempt to run a hack in the background, thereby reducing CPU load and saving more power, leading on to longer battery life and reduced heat generation. It also locks the screen as the lid is closed.

As it stands, the script is as follows:

#!/bin/bash

XUSER=`ps -C startx -o user h`
[[ 0$XUSER == 0 ]] && XUSER=none

if [[ 0`cat /proc/acpi/button/lid/LID/state|cut -c 13-16` == 0open ]]
then
        # Lid has been opened
        
        if [[ $XUSER != none ]]
        then
                su - $XUSER -c DISPLAY=:0.0 xset dpms force on
                su - $XUSER -c "/bin/sed -i 's/^dpmsOff:.*$/dpmsOff:        0:30:00/' ~$XUSER/.xscreensaver"
                su - $XUSER -c "DISPLAY=:0.0 /usr/bin/xscreensaver-command -restart"
                su - $XUSER -c "DISPLAY=:0.0 /usr/bin/xscreensaver-command -cycle"
        fi
else
        # Lid has been closed

        if [[ $XUSER != none ]]
        then
                su - $XUSER -c "/bin/sed -i 's/^dpmsOff:.*$/dpmsOff:        0:00:10/' ~$XUSER/.xscreensaver"
                su - $XUSER -c "DISPLAY=:0.0 /usr/bin/xscreensaver-command -restart"
                su - $XUSER -c DISPLAY=:0.0 xset dpms force off
                su - $XUSER -c "DISPLAY=:0.0 /usr/bin/xscreensaver-command -lock"
        fi
fi

The script will send the display into DPMS off mode when the lid is shut, resulting in the backlight being turned off. Actually, it asks the X server to do this after 10 seconds of inactivity, because this is the smallest figure that xscreensaver will accept, for some reason. This is done indirectly, by changing the .xscreensaver file of the person in charge of the X server. The screen is then locked, but will not display a hack because it will detect the DPMS off state. On opening the lid, the display is forced on and the DPMS timout is set to 30 minutes. Xscreensaver is then told to cycle the hack, which will start displaying the hack as the screen is now not in a DPMS power saving mode.

Software Suspend kernel support

Software suspend does not work nearly as well with my Dell as with my old Sony VAIO. This has been traced down to a problem with the nVidia acceleration. I'll look into this in more detail in the future and write back with my findings.

CPU frequency scaling

One thing that CPU manufacturers today seem to be pushing above all else is the clock speed of their processors. This is a good thing if you need the extra speed, but most of the time, most people don't. The extra speed just drains batteries and generates heat. The major processor manufacturers realised this some time ago and started building in facilities to slow down their processors if required. In fact, both AMD and Intel are now doing this in their desktop processors.

The Dell Latitude C840 has an Intel P4-M processor in it (1.8GHz in my case, although various different options are available). This supports Intel's Enhanced SpeedStep, apparently, but the Linux ESS driver doesn't seem to think so. It does, however, work quite nicely with the "Intel Speedstep on ICH-M chipsets (ioport interface)" option. Obviously, the setup you need depends on your CPU and chipset, but these options work for me:

Component nameConfig tagState
CPU Frequency ScalingCONFIG_CPU_FREQBuilt in
Default CPUFreq governorCONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACEUserspace
CPU frequency table helpersCONFIG_CPU_FREQ_TABLEBuilt in
Intel Speedstep on ICH-M chipsets (ioport interface)CONFIG_X86_SPEEDSTEP_ICHBuilt in

That sorts out the kernel side of things, but you'll still need to change the speed. You could do this manually, but there are a few programs out there that will do this automatically. One that I would particularly recommend is powernowd, which uses several alrgorithms to decide the CPU speed, but basically runs it in slow mode when not needed, speeding up when applications demand more processing power. It can be downloaded as a Debian package or from the powernowd web site.

Valid XHTML 1.0Valid Screen CSSValid Printable CSS