Running (K)Ubuntu Linux on a Dell Latitude XT
With Kubuntu Intrepid 8.10, I can delightedly say that installing Linux in form of a Debian variant - my kernel/operating system of choice for most tasks - on a new Dell Latitude XT went flawlessly and got most of its hardware to work out-of-the-box. The remaining adaptations that I did on my system are mentioned here.
Note: I couldn’t get Kubuntu Hardy 8.04 in its AMD64 version to install
- the kernel wouldn’t find its installation CD with the Latitude XT attached to its Mediabase. The i386 version installed without a problem, so this is what I’m using right now. I would rather like to use my Intel Core 2 Duo CPU to its fullest extent, though, given that Kubuntu Hardy AMD64 works flawlessly on my other laptop, a Lenovo Thinkpad T61 (and yes, Adobe Flash and Java both work in the AMD64 version).
Update 2009-06-11: I am now running Kubuntu 9.04 (Jaunty) on my Dell
Latitude XT. This was quite a process, because, unfortunately, there
were a few severe regressions concerning Xorg and the associated
ATI/Radeon drivers. Please see below for details on how to use the new
Xorg server 1.6 (xorg 7.4) with the built-in ATI Radeon Xpress 1250
(updates marked with “Update 9.04”).
On the positive side, an updated wacom driver and kernel 2.6.30 now
enables finger touch input in addition to the stylus. And very
recently, first multi-touch patches have appeared on the input mailing
list. We are now finally getting close to decent touchscreen support
under Linux!
Hardware
Ubuntu’s “jockey” tool can be used to activate proprietary drivers. For the Dell Latitude XT, two such pieces are required: for the WLAN network card (I chose a Dell 1495, which translates to a Broadcom chipset supported out-of-the-box by kernels >= 2.6.24 but requires non-free firmware) and for the graphics chipset (which is an ATI). For the latter, both the radeon and the radeaonhd driver work well and have excellent xrandr 1.2 support, which would actually be important to me for accessing projectors and bigger screens using DVI, but I also need at least some 3D acceleration (e.g. to run Google Earth). Until radeon or radeonhd improve (or actually, they get merged again - it seems slightly silly to have two drivers for the same subset of chipsets), the fglrx driver is the best option, and “jockey” installs it without any further help (which translates to installing the xorg-driver-fglrx and kernel modules - linux-restricted-modules-generic for Kubuntu Hardy and fglrx-kernel-source for Kubuntu Intrepid - packages and setting fglrx in xorg.conf). Additionally, I set the options
Option “TexturedVideo” “on”
Option “VideoOverlay” “off”
Option “OpenGLOverlay” “off”
in the “Device” section of my xorg.conf for supposedly better speed and video support. I did not measure performance impact of these options, but they made video flicker when using “xv” output go away.
Using the fglrx driver on Kubuntu Intrepid, I currently get around 1900 FPS with glxgears (repeat the mantra: this is not a benchmark!) and nearly 800 FPS with fgl_glxgears. This is good enough for Google Earth and some desktop effects. KDE4’s kwin with compositing enabled now gives some decent eye-candy.
Attention:
Suspend-to-ram (described in further detail below) works for me with fglrx packages version 2:8.543-0ubuntu4 and kernel package version 2.6.27-11.22 and seems rock-stable so far. However, with the updated fglrx driver (downloaded ATI Catalyst 8.12 driver installer and created Ubuntu intrepid packages from it) version 2:8.561, suspend (both to-ram and to-disk) is broken! Don’t use the new driver version at this time.
Update 9.04:
With Xorg server 1.6 and the required fglrx 8.600 (i.e. Catalyst 9.4),
the Radeon R300 chipset (which is the basis of the built-in Radeon
Xpress 1250) is no longer supported. This means that with (K)Ubuntu
9.04, fglrx can no longer be used on the Dell Latitude XT without
reverting to the older Xorg version.
This is not a big problem for normal office work, though. The newest
open source radeon driver works well, including suspend-to-RAM and
suspend-to-disk support as well as working console switching.
Attention: The default kernel and radeon packages in (K)Ubuntu 9.04
will not work! With these packages, starting X often leads to hard
lockups and suspend/resume is completely broken, with console switching
also being problematic. After many tries, I managed to find a
combination that works well (stable so far), taking packages from the
upcoming Ubuntu 9.10 (Karmic). At the moment, I am running
linux-image-2.6.30-8-generic 2.6.30-8.9, xserver-xorg-video-radeon
1:6.12.2-0ubuntu1~xup~1, and xserver-xorg-core 2:1.6.0-0ubuntu14, and
they seem pretty stable so far. At the time of this writing, I highly
recommend to take (at least) these package versions. If you need to try
other versions, I found that the kernel has the biggest influence on
stability. When e.g. console switching does not work or the X server
locks hard on loading, first try another kernel, then another radeon
driver version.
The biggest plus of using radeon instead of fglrx as the xorg driver is
definitely working Xrandr 1.2 support; that is, connecting and
disconnecting external screens just works (finally, no longer being
Windows in this regard) and even has a nice GUI for KDE 4.2. I very
often use this for external DVI and VGA screens (with 1600+ resolution)
and for connecting projectors (via VGA) on the fly without restarting a
single application. Note that you will need to set an appropriate
virtual screen size in xorg.conf to be able to attach (and fully use)
higher-resolution screens than the internal display after starting
Xorg. I use “Virtual 3200 2000” (in section Screen, subsection
Display) to support my biggest screens. See my
xorg.conffor
reference.
The biggest minus is loss of 3D acceleration. Although DRI is enabled
(which requires loading the radeon kernel module, e.g. by appending a
line to /etc/modules) as evidenced by xdriinfo and glxinfo, performance
is very bad at the moment. glxgears produces around 320 FPS, and Google
Earth is unusable.
For some reason, jockey didn’t work for the Broadcom WLAN though, but manually installing the b43-fwcutter package makes the card work. Note that WLAN is still slightly flakey for me and I occasionally need to remove and reload the b43 module to make it work again when using WPA Enterprise with PEAP (it is stable with WPA Personal, though). Any hints on fixing this would be greatly appreciated.
The built-in SD card reader also works out-of-the-box, the device /dev/mmcblk0p1 can be mounted automatically using the respective KDE4 tool.
Wow, that was easy for the major hardware components required to use the laptop - congratulations to (K)Ubuntu for making this work well.
DMA harddisk problem
There is one problem, though: the system tends to freeze for 20-30 seconds, documenting the freezes in syslog with
Jun 1 21:29:30 voyager kernel: [41344.330771] hda:
dma_timer_expiry: dma status == 0x24
Jun 1 21:29:30 voyager kernel: [41354.317535] hda: DMA interrupt
recovery
Jun 1 21:29:30 voyager kernel: [41354.317544] hda: lost interrupt
messages. Fortunately, the solution is simple. Adding the “noapic” option to the kernel boot command line fixes the problem, and the system does not freeze. In /boot/grub/menu.lst, it is sufficient to append this option to the defoptions line, generating e.g. the following:
defoptions=quiet splash apparmor.enabled=0 selinux=1 enforcing=0 noapic
Setting screen brightness
To be able to modify screen brightness, which is one of the factors that can noticably increase battery run time, the package kpowersave needs to be installed and the respective kpowersave binary be started (best to let it start automatically upon KDE login). Then the key combinations Fn-Up and Fn-Down will change the screen brightness.
Update 9.04: kpowersave is no longer required, screen brightness can be changed with the default ACPI key bindings.
Enabling the internal microphone
The internal microphone also works out-of-the-box, but is unfortunately disabled/muted in the default ALSA settings. To enable recording from this internal mic, set (either using alsamixer on the command line or e.g. KMix) the “Digital Input Source” field to “Digital Mic " and both the “Capture” (not the “Capture 1”) and the “Digital” channels in the recording section to maximum volume and unmuted.
Bluetooth
If, at any time Windows Vista has been installed on the machine along with the Dell Vista drivers for the Bluetooth module, then it will not work by default under Linux. This can fortunately be fixed fairly easily by installing the Windows XP drivers again, which come with a different (and standards compatible) firmware. There is no need to actually install Windows XP, because the firmware “downgrade” and driver installation can also be done under Windows Vista.
First, get the latest Latitude XT Bluetooth drivers for Windows XP from the official Dell support web site. At the time of this writing, this was the file R181542.exe dated 2008-05-05. Executing it will extract the contents (by default to c:\dell\drivers\R181542). After extraction, abort the installation procedure and explicitly execute DFU.exe from the x32\DFU directory with administrative rights. Then manually install the Windows XP drivers (using device manager, “updating” the driver, and selecting the extracted DriversXP directory).
After that, the device is recognized as a standard HCI Bluetooth device by Cambridge Silicon Radio. However, for some reason, the required hci_usb module was not loaded automatically on my system. Adding this to /etc/modules makes Bluetooth work.
Fingerprint reader
The fingerprint reader is a standard UPEK device and supported well by the fprint library using its built-in upekts driver. Installing the libpam-fprint and fprint-demo packages, the fprint_demo binary should already be able to access the fingerprint reader. Users that should be able to use the device need to be members of the plugdev group.
To use fingerprints for authentication (e.g. login), the pam_fprint module can be used. One drawback is that it stores its templates in the respective user directory under ~/.fprint/prints, and therefore authentication security is subject to appropriately set access permissions (don’t allow anybody to overwrite the files or they will be able to login with their fingerprints!) and can not be used with an encrypted home directory (as in my setup). Nonetheless, once the directory has become available (to the respective application asking for authentication, i.e. typically root or the respective user account), it can be used for any application capable of using PAM. I use it for unlocking the screensaver with fairly short automatic lock timeouts. Thus, for login, I enter my (strong) password to automatically decrypt my home directory as documented here, and once logged in, I unlock my laptop with a swipe of my finger. To me, this is a good compromise between security and usability.
For authentication, it’s necessary to first enroll the fingerprints. This can be done on by using the pam_fprint_enroll utility from the respective user account, e.g. for the right thumb using pam_fprint_enroll -f 6 (which will consequently be stored as ~/.fprint/prints/0001/00000000/6).
Unfortunately, kscreensaver as well as kdm don’t support “alternative” PAM authentication modules even in KDE 4.1. For logging in, I don’t need this right now, but unlocking the screensaver by just swiping the finger is something I wanted to have. gnome-screensaver, on the other hand, supports this quite well and I have therefore switched to Gnome’s screensavers instead of KDE’s. This is easily done by installing the gnome-screensaver package and its dependencies and simply starting gnome-screensaver . It can be configured using gnome-screensaver-preferences (although no options for the actual screen saver…). Fingerprint authentication can be enabled simply by adding the line
auth sufficient pam_fprint.so
as the first one to /etc/pam.d/gnome-screensaver.
Touchscreen
Update: Starting 2008-11-14, the integrated N_Trig touch screen works partially. That is, I can use the stylus to move the cursor and for left- (tapping) right- (the larger button on the stylus), and middle-click (the smaller button on the style), but direct finger touch does not work right now. (K)Ubuntu 8.10 already includes kernel 2.6.27 which supports the N-Trig USB device with HID events. Using the xserver-xorg-input-wacom package, the cursor can already be moved, although quite erratically. To make it usable, get the patch linuxwacom-0.8.1-3.ntrig_hack.patch from here. It applies cleanly to the Kubuntu 8.10 wacom-tools package version 0.8.1.4-0ubuntu3. I suggest to get it using “apt-get source wacom-tools”, apply that patch, update the package version to something akin to a NMU release, recompile and install the new driver. Alternatively (if you trust me and my security measures for this page), you can just install my patched and pre-compiled version for x86-32 and x84-64. Note that the wacom-tools binary utilities package doesn’t need to be patched (the standard Ubuntu package works). I recommend installing it as well for finer control using “wacomcpl” and/or “xsetwacom” Then, add the following blocks to xorg.conf:
Section “ServerLayout”
# these lines should already be in the file
Identifier “Default Layout”
Screen “Default Screen”
Inputdevice “Synaptics Touchpad”
# but add these three
InputDevice “stylus”
InputDevice “eraser”
InputDevice “touch”
EndSection
# these are for the touch screen
Section “InputDevice”
Driver “wacom”
Option “Mode” “Absolute”
Identifier “touch”
Option “Type” “touch”
Option “ForceDevice” “ISDV4”
# Tablet PC ONLY
Option “Device” “/dev/input/event3”
# Option “Device”
“/dev/input/by-path/pci-0000:00:13.1-usb-0:2:1.0-event-mouse”
Option “TopX”
“0”
Option “TopY”
“0”
Option “BottomX”
“9600”
Option “BottomY”
“7200”
Option “USB”
“on”
EndSection
Section
“InputDevice”
Driver
“wacom”
Identifier
“stylus”
Option “Mode”
“Absolute”
# Option “Device”
“/dev/input/event3”
Option “Device”
“/dev/input/by-path/pci-0000:00:13.1-usb-0:2:1.0-event-mouse”
Option “Type”
“stylus”
Option “ForceDevice” “ISDV4”
# Tablet PC ONLY
Option “TopX” “0”
Option “TopY” “0”
Option “BottomX” “9600”
Option “BottomY” “7200”
Option “USB” “on”
Option “Button1” “1”
Option “Button2” “3”
Option “Button3” “2”
EndSection
Section “InputDevice”
Driver “wacom”
Identifier “eraser”
Option “Type” “eraser”
Option “Mode” “Absolute”
Option “ForceDevice” “ISDV4”
# Tablet PC ONLY
# Option “Device” “/dev/input/event3”
Option “Device”
“/dev/input/by-path/pci-0000:00:13.1-usb-0:2:1.0-event-mouse”
Option “TopX” “0”
Option “TopY” “0”
Option “BottomX” “9600”
Option “BottomY” “7200”
Option “USB” “on”
Option “Button1” “2”
Option “Button9” “0”
EndSection
Section “ServerFlags”
Option “AutoAddDevices” “False”
EndSection
I’m still waiting for finger touch support, but it’s already quite usable.
Many thanks go to Howard Chen for providing hints on how the “eraser” block can actually be used to make the second (smaller) stylus button work. He contributed the “Button1” and “Button9” mapping for this block. If there is any erratic scrolling caused by the stylus, he also recommends satting “xsetwacom set stylus StripLDn 0 && xsetwacom set stylus StripLUp 0” on login, e.g. in .kde/Autostart. It’s not necessary for me, but may help in case of problems.
Update 9.04
(K)Ubuntu 9.04 uses a newer wacom-tools package, but the newest version
of the N-Trig patches will not apply cleanly to the package shipped in
Jaunty. Instead, I use the upcoming Karmic package version and applied
the newest patches from
here again. You can download
my pre-compiled xserver-xorg-input-wacom package for
x86-32
(again, wacom-tools do not need to be updated).
The configuration part in xorg.conf has been slightly simplified and
finger touch input is now supported and working unexpectedly well
(subjectively, it seems more accurate than under Windows Vista with
N-Trig’s own drivers!).
Section “ServerLayout”
Identifier “Default
Layout”
Screen “Default Screen” 0
0
InputDevice “Synaptics
Touchpad”
InputDevice
“stylus”
InputDevice
“eraser”
InputDevice
“touch”
EndSection
Section “InputDevice”
Identifier “Synaptics Touchpad”
Driver “synaptics”
Option “Device” “/dev/psaux”
Option “Protocol” “auto”
Option “HorizEdgeScroll” “0”
Option “SHMConfig” “on”
EndSection
# This section is for the TabletPC that supports touch
Section “InputDevice”
Identifier “touch”
Driver “wacom”
Option “Mode” “Absolute”
Option “Device”
“/dev/input/by-path/pci-0000:00:13.1-usb-0:2:1.0-event-mouse”
Option “Type”
“touch”
Option “TopX”
“0”
Option “TopY”
“0”
Option “BottomX”
“9600”
Option “BottomY”
“7200”
Option “Touch”
“on”
Option “Supress”
“0”
EndSection
Section “InputDevice”
Identifier “stylus”
Driver “wacom”
Option “Mode” “Absolute”
Option “Device”
“/dev/input/by-path/pci-0000:00:13.1-usb-0:2:1.0-event-mouse”
Option “Type”
“stylus”
Option “Touch”
“on”
Option “Button1”
“1”
Option “Button2”
“3”
Option “Button3”
“2”
EndSection
Section “InputDevice”
Identifier “eraser”
Driver “wacom”
Option “Mode” “Absolute”
Option “Device”
“/dev/input/by-path/pci-0000:00:13.1-usb-0:2:1.0-event-mouse”
Option “Type”
“eraser”
Option “Button1”
“2”
Option “Button9”
“0”
EndSection
My full xorg.conf contains these and a working radeon configuration blocks.
I definitely recommend to take a look at Jarnal or Xournal (the latter has Debian/Ubuntu packages in the main repositories) - both make taking notes with the stylus nice and support annotating PDFs. I’ve used Jarnal to make notes on research papers I read instead of printing then out, because being written in Java, I can read the (SVG-based) file format on any platform. Xournal works better in terms of strokes and general handling but (so far) uses its own, incompatible file format.
Config files
- xorg.conf for (K)Ubuntu 8.10: includes custom fglrx options and support for N-Trig touch screen
- xorg.conf for (K)Ubuntu 9.04: includes minimal blocks for using the radeon drivers and support for N-Trig touch screen with finger touch input in addition to stylus input
Software
Versioning /etc
The first change I often try to do when setting up a new Linux system is to version all files under /etc. Michael Prokop has described this nicely for mercurial, the DVCS of my choice, and I just use his recipe (copied here mostly for my own reference):
- cd /etc
sudo hg init
sudo chmod og-rwx .hg - sudo jed .hgignore
(or use any other editor) and insert:
syntax: regexp (^)*.dpkg-new (^)*.dpkg-old (^)blkid.tab(|.old) (^)mtab .svn # add other files if necessary, depends on your setup… - sudo hg add
sudo hg ci -m “initial checkin” - sudo jed /etc/apt/hg-snapshot-script
insert:
#!/bin/sh
set -e
caller=$(ps axww | mawk ‘/aptitude|apt-get/ {for (i=5; i<=NF ; i++) printf ("%s “,$i); printf (”\\n”) }’ | head -1) hg addremove 1>/dev/null STATUS="$(hg st)" if [ -z “$STATUS” ] ; then echo “hg-snapshot-script: nothing to be done” else case “$1” in pre) echo “hg-snapshot-script: found changed files:” hg st hg ci -m “snapshot from $LOGNAME before: $caller” ;; post) echo “hg-snapshot-script: found changed files:” hg st hg ci -m “snapshot from $LOGNAME after: $caller” ;; *) echo “hg-snapshot-script: found changed files:” hg st hg ci -m “snapshot from $LOGNAME on $(date ‘+%Y-%m-%d - %H:%M:%S’)” ;; esac fi - sudo chmod +x /etc/apt/hg-snapshot-script
- sudo jed /etc/apt/apt.conf.d/90local-hg-snaphot
and insert:
DPkg {
Pre-Invoke {“cd /etc ; ./apt/hg-snapshot-script pre”;};
Post-Invoke {“cd /etc ; ./apt/hg-snapshot-script post”;};
} - hg add
hg commit -m “apt will track /etc automagically using hg”
Adding more apt repositories
The default selection of packages in Ubuntu is extensive, but still not
complete. Especially in terms of media codecs, the Medibuntu repository
is a helpful addition. This can be added by e.g. creating a file
/etc/apt/sources.list.d/medibuntu.list with the line
deb http://packages.medibuntu.org/ hardy free non-free
Virtualbox
Unfortunately, after buying InnoTek, Sun seems to find “interesting” excuses for not making Virtualbox apt-gettable anymore. This means that the Virtualbox Debian packages need to be downloaded from the Sun homepage and that automatic updates will no longer happen.
Update: Starting with Virtualbox 2.0, it is again apt-gettable. Very
good! The respective package signing key can be added with
wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc -O- | sudo apt-key add -
Then, add a file /etc/apt/sources.list.d/virtualbox.list with the line
deb http://download.virtualbox.org/virtualbox/debian hardy non-free
At the time of this writing, I am using Virtualbox 2.0.2 (the free but
non-open-source edition because I need USB support). Installing the
package is painless and by executing
sudo /etc/init.d/vboxdrv setup
it will already work. That’s certainly a nice step forwards from the
involved procedure the VMWare workstation always required. For USB
support, however, another step is necessary, namely to add a line to
/etc/fstab:
none /proc/bus/usb usbfs
auto,busgid=120,busmode=0775,devgid=120,devmode=0664 0 0
and add all users that should be allowed raw access to the USB devices
in the vboxusers group. Note: Depending on your installation order, the
vboxusers group may have another GID than 120. Use the respective GID
for the fstab entry.
Sensible configuration for sudo
The next thing to change on a typical (K)Ubuntu install is to make the sudoers configuration more sensible:
- Move the block for group admin to the top of the file, right after dealing with environmental variables and before the definition for group sudo, which should be uncommented. The reason is that, when processing the sudoers file, the last match counts. This took me quite some time to figure out why I was asked for the user password although this user belonged to the sudo group, and should thus be allowed to use sudo without a password.
- Allow language and ssh environment variables to be passed into the sudo environment by adding “SSH_*” to env_keep. Otherwise, ssh-agent authentication won’t work for all commands called with sudo.
My sudoers file typically looks like this:
Defaults env_reset Defaults env_keep+="LC_*" Defaults env_keep+="SSH_*" Defaults env_keep+="EDITOR" Defaults env_keep+="EMAIL" Defaults env_keep+="NAME"
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Uncomment to allow members of group sudo to not need a password
%sudo ALL=NOPASSWD: ALL
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification root
ALL=(ALL) ALL
This makes working with sudo a bit nicer.
Standby aka. suspend-to-RAM
Suspend to RAM works basically out-of-the-box (yeah, Ubuntu!) and can
be triggered by closing the lid simply by modifying
/etc/acpi/events/lidbtn to trigger /etc/acpi/sleep.sh as its action
instead of the default /etc/acpi/lid.sh (which, by default, would only
activate the screensaver and turn off the display backlight). I prefer
this setup, as it will put the machine into suspend-to-RAM by closing
the lid and wake it up by opening it again (typically within a few
seconds).
Note that this works without modifying /etc/default/acpi-support.
Update: Instead of modifying /etc/acpi/events/lidbtn, there is a better solution that avoids the occasional resume-and-immediately-go-back-to-sleep problem when opening the lid. The problem is seemingly that a second “lid” ACPI event is triggered, causing the sleep.sh script to be executed again. This can be prevented by explicitly checking if the lid is closed. The acpi-support package offers some convenient hooks which we can use for this purpose. I created the directory /etc/acpi/local and in it the file /etc/acpi/local/lid.sh.pre with the content:
#!/bin/sh
grep -q closed /proc/acpi/button/lid/*/state && /etc/acpi/sleep.sh sleep
After making this file executable, the “lid” ACPI event will by default trigger the /etc/acpi/lid.sh script, which in turn will now start /etc/acpi/sleep.sh only if the lid is actually closed.
There is one additional modification that I made to automatically lock the screen before going into suspend-to-RAM mode so that a password (or fingerprint, see above) is required to use the machine after resume. (K)Ubuntu typically relies on the desktop environments to do this, but this doesn’t seem to work with my mix between KDE 4.1 and Gnome screensaver. Therefore, I extended the /etc/acpi/sleep.sh script to explicitly execute the screensaver:
#!/bin/bash
. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs
. /usr/share/acpi-support/device-funcs
. /usr/share/acpi-support/policy-funcs
DeviceConfig;
if [ x$ACPI_SLEEP != xtrue ] && [ x$1 != xforce ]; then
exit;
fi
# If gnome-power-manager or klaptopdaemon are running, let them handle policy
if [ x$1 != xforce ] && [ x$1 != xsleep ] && [ `CheckPolicy` = 0 ]; then
exit;
fi
if [ x$LOCK_SCREEN = xtrue ]; then
if pidof xscreensaver > /dev/null; then
for x in /tmp/.X11-unix/*; do
displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
getXuser;
if [ x"$XAUTHORITY" != x"" ]; then
export DISPLAY=":$displaynum"
. /usr/share/acpi-support/screenblank
fi
done
else
# local hack RM: if gnome-screensaver is not running, start it and immediately lock
for x in /tmp/.X11-unix/*; do
displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
getXuser;
if [ x"$XAUTHORITY" != x"" ]; then
export DISPLAY=":$displaynum"
if ! pidof gnome-screensaver > /dev/null; then
su $user -c "gnome-screensaver"
fi
su $user -c "gnome-screensaver-command --lock"
fi
done
fi
fi
# Generic preparation code
. /etc/acpi/prepare.sh
if [ x$DISABLE_DMA = xtrue ] && [ -b /dev/hda ]; then
hdparm -d 0 /dev/hda
fi
echo -n $ACPI_SLEEP_MODE >/sys/power/state
if [ x$RESET_DRIVE = xtrue ] && [ -b /dev/hda ]; then
hdparm -w /dev/hda
hdparm -C /dev/hda
hdparm -C /dev/hda
hdparm -C /dev/hda
hdparm -d 1 /dev/hda
fi
if [ x$DISABLE_DMA = xtrue ] && [ -b /dev/hda ]; then
hdparm -d 1 /dev/hda
fi
# Generic wakeup code
. /etc/acpi/resume.sh
Note the “local hack” which starts gnome-screensaver if it isn’t running and then locks all active screens with it. On wakeup, I just have to swipe my finger to use the system again after only a few seconds - nice compromise between security and usability.
Hibernate aka. suspend-to-disk
Suspend to disk needs the uswsusp package (it can be done with others,
but this is what I use with success), so it needs to be installed. Then,
a dpkg-reconfigure uswsusp will trigger its configuration. I chose not
to perform a checksum, to compress the image, to perform early write
out, and - most importantly - to encrypt the snapshot using RSA key with
2048 Bits. I strongly advise everybody to encrypt the suspend snapshot,
as otherwise everybody gaining access to the suspended machine may get
access to plain-text passwords, crypto keys, etc. which had been in
memory at the time of suspending. Using an RSA key is a reasonable
compromise between security and usability: suspending the machine will
not ask for a password (it really shouldn’t), only for resume it will be
required to enter the password that was configured in the
dpkg-reconfigure stage. It is advisable to choose a strong password!
To make it work, /etc/acpi/hibernate.sh needs to be fixed so as to call
s2disk without broken parameters even when /etc/usplash.conf exists.
Update: Actually, the s2disk tool included with uswsusp is unable to
send the machine to actually switch off. The reason might be the fglrx
driver, although I haven’t tried s2disk without this driver loaded. The
good news is that right-clicking on the kpowersave icon and selecting
either “Suspend to Disk” or “Suspend to RAM” from its menu works nicely
for both methods. This is also integrated with the Ctrl-Alt-Del KDE4
popup (clicking and holding for a few seconds on the “Turn Off Computer”
button) and it should be possible to activate those methods by events as
well (Fn-key combinations and closing the lid).
The clear disadvantage is that, in contrast to using uswsusp, there is
not yet an easy way to encrypt the suspend-to-disk snapshot. Very bad
when the laptop gets lost… I will try to come up with a nice solution
that doesn’t require entering a password during normal bootup (which the
combination of this suspend-to-disk mechanism with a LUKS encrypted swap
would) and post it here when it’s working.
Update 2: Without the proprietary fglrx module but using radeon, s2disk works nicely, including its built-in compression and encryption.
There might be a small catch in getting suspend-to-disk to work for the first time with either of the methods. When /etc/initramfs-tools/conf.d/resume doesn’t contain the UUID of your swap partition (initially, it didn’t in my case), then manually entering it (e.g. RESUME=/dev/hda6) and calling sudo dpkg-reconfigure initramfs-tools should fix this file. Afterwards, it should have the format RESUME=UUID=<your swap partition UUID>, which is expected by the /etc/acpi/hibernate.sh script.
TODO: encrypted swap and /tmp
Debian unstable chroot
