next up previous
Next: Update 19 July 2004: Tech Support and the failed motherboard Up: Installing Debian GNU/Linux on a Dell Inspiron 5100 Laptop Previous: Networking: Nothing But Trouble

Subsections


Miscellany


Sound

Sound works. The owner's manual calls the sound card a ``Sigmatel C-Major Audio''; it uses the driver i810_audio. I'd like the keyboard volume controls to work, just because I prefer hardward to software controls, but that feels like one of those things that I'll never get around to doing. Somewhere I saw instructions how to do that.


USB

USB was tricky for the wrong reason. The machine has a USB 2.0 controller, and the USB 2.0 driver (ehci-hcd) is ``experimental code'' and didn't show up in my kernel config until I asked to see experimental options. Now the magic works. I also seem to need the drivers usb-uhci and usb-storage, though I haven't tried running without them.


PCMCIA

This worked right off, though I had trouble finding the right driver for my card. [*]


Firewire

The firewire module (ieee1394) loads successfully. I don't have any hardware to test it with.


Power Management

This sort of works. The power button works, anyway. ACPI is another ``experimental'' bit of code in the kernel.

I can't find how to send the thing to sleep. Echoing numbers to /proc/acpi/sleep seems to either hang or crash the machine; pressing the power button undoes the hang, then shuts the machine off, darn it.

I found a program called swsusp which claims to suspend to disk, like the Windows command ``hibernate.'' I couldn't get it to work. This is probably the feature I would use most; I hear it will be included in the 2.6 kernel.

What I can't do is learn about the charge on the battery or the temperature of the CPU. The second I don't mind so much, but the first is sort of a pain: if I use the machine unplugged I have no clue short of the idiot light on the front as to how much battery I have. It seems to last for a while, but I haven't really pushed it.

I've read that it works.


Update 19 July 2004: Software Suspend (``Hibernation'')

I have suspend-to-disk working in kernel 2.4.26 using the swsusp 2.0 patches from http://softwaresuspend.berlios.de/. The process was pretty easy. There are two patches to apply to the kernel: a kernel-specific patch which must match your running kernel, and a ``core patch'' which is applied after that. Reconfigure the kernel and say ``yes'' to Software Suspend and the Swap Writer under ``General Setup.'' Install this kernel as the default (under LILO or GRUB or your bootloader) with append="resume2=swap:/dev/hdc10" in order to enable recovery from hibernation. Then use the hibernate script from the swsusp distribution (follow the links from the homepage to the ``berlios download page'') and you can suspend with sudo hibernate.

I'm using swsusp 2.0 and suspend-script-0.94.

By default the hibernate script doesn't do very much before it takes the machine down. Some of the modules (especially the modem driver) didn't handle this well, and USB acted funny after hibernation, and gpm lost control of the touchpad. However the hibernate script is easy to modify. I have it unload all the modules, unmount any removable drives (/floppy etc.) and stop hotplug before suspending. After resuming it reloads from /etc/modules (like at boot), restarts gpm, and starts hotplug. Pretty flawless.

ACPI Update 13 September 2003: Battery support in 2.4.22 kernel

ACPI is fully functional with kernel 2.4.22, with the dsdt patch for the Dell Inspiron 5100 from http://acpi.sourceforge.net. You have to patch the kernel to use the new dsdt, but you don't have to apply an ACPI patch. Follow Matt Perry's instructions.

None of the GNOME battery monitors seem to work; that may be a Debian stable-vs-testing issue. I'll play with that soon.

Apparently the behavior I observed with the machine hanging reversibly is actually the operation of the ACPI driver; the thing looks frozen because it doesn't blank the screen before it stops. This isn't quite what I wanted. I'll hold out for swsusp in the 2.6 kernel. (Update: This works now, see Section [*].)

Interestingly, while the battery monitor (acpi -V) does a good job of estimating the remaining lifetime of the battery, it does a lousy job of guessing charging time. The file /proc/acpi/battery/BAT1/state reports typical charging rates of 62000 mA, which would trip a working circuit breaker. But that is a small problem.

ACPI Update 23 September 2003: LCD Backlight on/off with lid

Thanks to ThanhVu Nguyen, I have taught acpid to turn off the LCD backlight when I close the lid. Here's how:

  1. I downloaded radeontool and put it in /usr/local/bin.

  2. I put the following text in a file called /etc/acpi/events/lid: 
    # turn the backlight on and off to correspond with the state of the lid
# based on /etc/acpi/events/powerbtn

event=button[ /]lid
action=/etc/acpi/lid.sh
    and the following in /etc/acpi/lid.sh: 
    #!/bin/sh

# lid.sh
# Copyright 2003 Rob Mahurin <rob@utk.edu>
# Available for use under the General Public License
# No warranty etc.
   
XSC=/usr/bin/xscreensaver-command
XSET=/usr/bin/X11/xset 
# XSET=/bin/false  # uncomment this or something similar to not use DPMS

die() {
    echo "Unable to determine state of lid."
    exit 1
}

lockall() {
    for i in /tmp/.X11-unix/X* ; do
        num=$(basename $i | cut -b2-)
        export DISPLAY=:${num}.0
        echo "Locking display " $DISPLAY
        $XSC -lock
    done
}

RADEONTOOL=/usr/local/bin/radeontool
[ -x $RADEONTOOL ] || exit 0

STATEFILE=/proc/acpi/button/lid/LID/state
[ -f $STATEFILE ] || die;
STATE=$(awk '{ print $2 }' < $STATEFILE)

case "$STATE" in
    "closed")
        echo "Lid is closed.  " 
	echo "Turning off backlight." && $RADEONTOOL light off
        lockall
	[ -x $XSET ] && echo DPMS off && $XSET dpms force off
        ;;
    "open")
        echo "Lid is open.  Activating backlight."
	[ -x $XSET ] && echo DPMS on && $XSET dpms force on
        $RADEONTOOL light on
        ;;
    *)
        $RADEONTOOL light on
        die
        ;;
esac

  3. Restart acpid. If you say sudo /etc/init.d/acpid restart from an environment where sudo xterm would work, acpid will have permission to lock your xscreensaver. If you just let acpid start when the machine boots, the lockall function in lid.sh will fail harmlessly. This is nice for me, since I occasionally work in a security-paranoid place and being able to lock the screen and save the battery simultaneously is a Good Thing.

Update 11 April 2005: Ulrich Dangel writes to tell me that he has changed lid.sh so that it locks the display without having to use the sudo trick. You can get his script from him at http://spamt.net/acpi/lid.sh.

ACPI Update 25 September 2003: LCD Backlight with DPMS

Run a script like this one to have radeontool work with xscreensaver's DPMS (power management) setting. Notice the person running the script needs to have permission to use radeontool.

I like this better than lightwatch.pl because it's independent of xscreensaver and permits me to use screen locking - lightwatch.pl presents the xscreensaver password box without turning the LCD back on. 


#!/bin/bash

################################################################
 # dpmswatch.sh
 # Copyright 2003 Rob Mahurin <rob@utk.edu>
 # Available for use under the General Public License
 # No warranty etc.
 ##
 #  This is based on lightwatch.pl, but instead of using 
 #  xscreensaver-command -watch, it uses xset to query the DPMS state
 #  of the LCD.  If the desired DPMS state is off, blank the LCD 
 #  backlight using radeontool.
 ##
 #  If your system gives a different output to this command :
 #  $ for i in standby suspend off on ; do 
 #      xset dpms force $i ; 
 #      xset q ; 
 #    done | grep Monitor | awk '{print $3 $4 }'
 #    inStandby
 #    inSuspend
 #    Off
 #    On
 #  then you may have to modify this script.
 ##
 #  It's written in shell instead of Perl because that's what I know.
################################################################

# commands to use.  Correct on Debian woody.
XSET=/usr/bin/X11/xset
# radeontool is broken on Debian testing.
#RADEONTOOL=/usr/local/bin/radeontool
RADEONTOOL=/bin/true

# also look at the state of the lid.  Don't change anything if it is
# closed.
STATEFILE=/proc/acpi/button/lid/LID/state

# The polling intervals, for feeding to sleep(1).  Is there way to
# make this event-driven, rather than poll all the time?  Does it
# matter?
#
# Notice that we don't want to watch the xscreensaver, since that
# would bring up the password box without turning on the LCD.  Very
# confusing.
inStandby_INTERVAL=5s   
inSuspend_INTERVAL=5s
Off_INTERVAL=1s
On_INTERVAL=5s
INTERVAL=0s;

# check to make sure we have all the commands we need
for i in $XSET $RADEONTOOL
do    [ -x $i ] || { echo $i not found >&2 || exit 0 ; } 
done

while : ; do 
    # what is the state of the monitor?
    STATE=$($XSET q | grep Monitor | awk '{print $3 $4}')

    # what is the state of the lid
    OLDLIDSTATE=$LIDSTATE
    [ -f $STATEFILE ] &&
	LIDSTATE=$(awk '{ print $2 }' < $STATEFILE) ||
	LIDSTATE=open 

    # if the monitor is closed, set DPMS off (so the screensaver
    # doesn't run).  If it has just opened, turn DPMS back on.
    [ "closed" = "$LIDSTATE" ] && 
	xset dpms force off && INTERVAL=$Off_INTERVAL
    [ "open" = "$LIDSTATE" ] && [ "closed" = "$OLDLIDSTATE" ] && 
	xset dpms force on && STATE="On"

    # if the monitor is in standby or suspend, change the polling
    # interval but turn the light on or off.  If the monitor is Off,
    # turn off the LCD backlight.  If the monitor is On, turn on the
    # backlight.  Then sleep until it's time to check again.

    [ "open" = "$LIDSTATE" ] && case $STATE in 
        inStandby) 
                INTERVAL=$inStandby_INTERVAL 
                ;;
        inSuspend) 
                INTERVAL=$inSuspend_INTERVAL 
                ;;
        Off)    
                INTERVAL=$Off_INTERVAL
                $RADEONTOOL light off
                ;;
        On)     
                INTERVAL=$On_INTERVAL
                $RADEONTOOL light on
                ;;
        # if something strange happens, turn the light on and fail.
        *)      
                $RADEONTOOL light on
                exit 1
                ;;
    esac
    sleep $INTERVAL
done &

ACPI Update 19 July 2004: New system board, BIOS A30

After my hardware problems (see section [*]), Dell gave me a new motherboard. This had an updated version of the BIOS software, version A30, and ACPI no longer worked under kernel 2.4.22. Under kernel 2.4.26, it works enough for me, but I don't get events, which means that I can't use the power button to execute a shutdown and I can't do software things when the lid closes. That's kind of a downer.

From the ACPI section of the kernel config, I have selected 

 [*] ACPI Support            
 <*>   AC Adapter            
 <*>   Battery               
 <*>   Button                
 <*>   Fan                   
 <*>   Processor             
 <*>   Thermal Zone          
 < >   ASUS Laptop Extras    
 < >   Toshiba Laptop Extras 
 [ ]   Debug Statements      
 [*]   Relaxed AML Checking

The ac adapter, battery, and thermal zone sections all seem to work. The lid, power, and sleep ``buttons'' are all recognized, though without events they don't do much. The processor is recognized; I'm able to e.g. slow it down by 87% by typing echo -n 7 > /proc/acpi/processor/CPU0/throttling. /proc/acpi/fan is an empty directory. Changing the ``relaxed AML checking'' doesn't seem to have any effect.

I should note that this is with a stock 2.4.26 kernel. If I follow Matt Perry's instructions, I get the same broken behavior (ACPI unaware of battery). Probably I am done messing with this.

next up previous
Next: Update 19 July 2004: Tech Support and the failed motherboard Up: Installing Debian GNU/Linux on a Dell Inspiron 5100 Laptop Previous: Networking: Nothing But Trouble
Rob Mahurin 2005-04-11