Fedora 9 Sulphur on a Dell Latitude D430

The Latitude D430 by Dell is a small laptop, which I find very convenient apart from the separated DVD drive. I used Fedora 8 on it for a few months, but I never took time to document the small tricks I had to apply to reach a fully usable system. The goal of this document is to fill this gap for Fedora 9.

Initial installation

I've made a fresh install (wiping everything out) from the x86_64 DVD, as I wanted to encrypt the hard drive. Everything went on quite smoothly except for one small problem: I've selected the XFCE desktop but it wasn't installed...

Then the mandatory updates are needed. A good idea is to install first the yum-fastestmirror package, so that you won't wait for ages for your downloads to complete. As root, simply type:

yum install yum-fastestmirror

I also installed yumex, which I find convenient sometimes (I generally prefer the command line, but guis are very helpful in some situations). So again as root:

yum install yumex
and proceed to the updates by:
yum update

While PackageKit gui looks goods (apart from the huge icons) I was not able to find a way to tell it to install several packages at once, something very boring. As an alternative to yumex, you might consider smart.

And then what? All in one, Fedora 9 is almost ready for service after a fresh install and all the updates. Some post install configuration is needed for the hardware, as explained in the next section. The software itself if not perfect so I've gathered a few tricks to enjoy Fedora. By definition of the present document the software tricks should be completely independent of the hardware, but who knows ;-)

Hardware

Most of the (reasonable) hardware of the D430 is readily recognized by Fedora 9 out of the box. There are nevertheless a few things to tune.

Status of the D430 hardware:

Status of external hardware:

Hard drive

Of course, the hard drive of the D430 is recognized by Fedora 9. However, Fedora faces the dreaded "disk killer" problem (which is basically faced by any OS, see e.g., this for Ubuntu).

Modern laptop drives have indeed the ability to suspend their activity (unloading the heads, as far as I understand). This reduces the power consumption of the disk, which is obviously good for a laptop on battery. However, a hard drive can only sustain a limited number of load cycles, so you don't want this to happen too frequently.

On my D430 (your millage may vary), the hard drive is a model by Toshiba with reference mk1011gah. According to the specs, it can last 20 000 hours. Unfortunately, Toshiba does not provide data about the number of load/unload cycles the drive can sustain. Hitachi says that 300 000 load/unload cycles are standard figures and according to the Ubuntu bug page, 600 000 is also quite standard value. Therefore, you don't want more than 15 to 30 load/unload cycles per hour to avoid shortening the hard drive life.

Unfortunately, the Toshiba drive default configuration seems to be more aggressive. This can be easily tested by the following simple instruction (as root)

while true ; do smartcl -a /dev/sda | grep Load_Cycle ; sleep 60 ; done
The effect of this simple script is to query every minute the S.M.A.R.T. attributes of the hard drive and to print the value of the Load_Cycle (as a side effect, this will probably wake up the disk every minute). When connected to the power line, the Load_Cycle increases by about 2 units per minute, i.e., 120 per hours (when the computer is otherwise idle and even if I look at the Load_Cycle only every 10 minutes). This is way too much. More over, there tend to be more than 2 load/unloading operations per minute when the drive is active!

To solve the problem, one has to play with the hdparm command to reduce the frequency of the load/unload operations. The following command (as root) gives the current setting of the hard drive :

hdparm -I /dev/sda
Among all the things reported, the important part (for the load/unload problem) is this
Advanced power management level: 128
Recommended acoustic management value: 254, current value: 128
The lower APM level, the more aggressive the unloading will be. Clearly, the standard value is way too low. On my laptop, setting it to the recommended value with
hdparm -B 254 /dev/sda
turns of the load/unloading which if fine the laptop is operating on a power line (up to a possible increase in temperature, one has to be extra careful with laptops). Unfortunately, it also turns off the feature when operating on battery, as the disk is not aware of the power status. As a consequence, the laptop will tend to waste power. Moreover, unloading provides also rudimentary protection against shocks, something quite useful on a laptop.

This means basically that the status of the power source must be monitored to change the value of the APM level accordingly. But before doing that, one need to chose an appropriate APM level for the battery case. This can be done by changing the APM level and monitoring the Load_Cycle. You have to increase the delay between two requests to avoid waking up the disk spuriously. On my D430, an APM level below 190 induces at least one load/unload cycle per minute even when the disk is under heavy usage (e.g., during an update of the system).

Once you have chosen the APM levels, the solution is to rely on the Pm-utils infrastructure, following the instructions given here. Basically you have to create some configuration file, choosing the APM level and other settings. This is very clearly explained on the OpenSuse web site, so follow the instructions! I simply recommend to use the -B 254 setting rather than the -B 255, as the first one doesn't work for me. You need to have the pm-utils package installed, but this seems to be a core package.

Display (External screen and extended desktop)

The D430 features a wide 12 inches screen with a resolution of 1280x800 powered by an Intel GPU 945GM. It is automatically recognized by Fedora which uses the intel driver for X.org.

Moreover, dual screen has been greatly simplified compared to Fedora 8 thanks to all the work done to support xrandr in gnome-display-properties and krandrtray (depending on your desktop). Several issues remain:

  1. the magic key (Fn+F8 on the D430) does not work (it generates an "unknown key pressed (translated set 2, code 0x8b on isa0060/serio0)" message in the kernel log). I guess it can be fixed with a similar trick as the one proposed here, but this seems a bit complicated. See below for my ongoing quest for a simple solution.
  2. extended desktop won't work until some modifications (found in the documentation by Intel and in a thinkpad oriented documentation) are implemented in the stock /etc/X11/xorg.conf (don't count on system-config-display to do the work for you, it seems to have a serious bug related to dual display, as I experienced an index out-of-bounds exception in the python code when I tried to use it). The key point is to enable a large virtual size to accommodate for the glued displays: I have for instance an external screen with resolution 1024x768. If I set the LCD of the laptop to the same resolution, then I need a virtual resolution of at least 2048x768 if I want to use the screens side by side.
    This is done by adding a Virtual directive in the Display subsection of the screen Section, like this:
    Section "Screen"
            Identifier "Screen0"
            Device     "Videocard0"
            DefaultDepth  24
            SubSection "Display"
                    Viewport 0 0
                    Depth    24
                    Virtual  2048 2048
            EndSubSection
    EndSection
    
    The non informative names come from the default configuration, you can of course fix them. The important point is to add a Virtual line. As I've a 945GM GPU, I've used the maximal virtual sizes that will work with DRI. it.
    If you don't implement this modification, you will be limited in practice to cloned displays (i.e., the same display on the laptop and on the external screen). This solves the beamer problem caused by the missing magic key.
  3. Under KDE, nothing is working. When the 3D desktop is enabled, the system is very unstable with frequent kwin crashes (whereas compiz works perfectly). When it is not enabled, the behavior of the system is quite random. For instance, if one starts a session with an external screen connected, the panel might refuse to display anything. Switching resolutions with krandrtray is completely broken (again, the panel might disappear). In System Settings (Display section), the apply button remains inactive after a modification of the parameters (e.g., screen size).
    All those problems seems to be related to KDE's tools, as the xrandr command line tool has the expected results even in KDE. For instance, the command
    xrandr --output LVDS --mode 1024x768 --output VGA --auto --same-as LVDS
    
    clone the displays and force the laptop to use a 4/3 screen resolution to accommodate the resolution of the external display that I'm using. Extended desktop, e.g.,
    xrandr --output LVDS --mode 1024x768 --output VGA --auto --below LVDS
    
    works also as expected. Moreover, all of this is compatible with the 3D effects.
So to summarize: A final warning under KDE with 3D effects: switching resolutions or doing other tricks with xrandr will sometimes blank the screen. To get it back use the keyboard short cut for displaying all desktops (default Ctrl+F8).

Keyboard

Of course the keyboard works correctly under Fedora, but some functionality available via the Function (Fn) key don't. Let's start with the working keys:

Most of the other keys don't work. To fix this, one has to use HAL with the famous "quirks". The problems come from the fact that the D430 is not recognized in the different models that HAL already knows. Indeed, the file
/usr/share/hal/fdi/information/10freedesktop/30-keymap-dell.fdi
does not contain anything related to the D430. However, there is a line with interesting information:
<match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains="D420;D820">
It turns out that the scancode specified in the lines that follow this match instruction are those generated by the special keys on the D430. To get the D430 special keys recognized, one only needs to replace the above line by the following version:
<match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains="D420;D430;D820">
and voila. Then restart the HAL daemon by (as root):
service haldaemon restart
and the special keys should partly work. By partly I mean that the brightness control keys and other keys don't generate any more error messages in the kernel log. Moreover, the battery key (Fn+F3) displays battery information and the suspend key (Fn+F1) sends the D430 to hibernation (suspend to disk, which works by the way perfectly), and the brightness control keys have nice animations. However, the screen toggle key (Fn+F8) still does not work and still generates a kernel message, whereas the corresponding code is declared in the quirk file. A manual
setkeycodes e00b 227
maps the key to the switch video mode keycode (KEY_SWITCHVIDEOMODE, according to /usr/include/linux/input.h), but I'm not sure this is the correct solution as this does not enable the wanted functionality. I need to do some experiments with other keys, as on X.org side, XF86Video and XF86Display are the correct codes. I guess that the only solution might be to rely on xbindkeys (see here and here for instance).

Touchpad

The touchpad works of course out of the box, but some tweaking is needed to get the best out of it. Installing gsynaptics/ksynaptics allows easy configurations of the touchpad features, but only after adding the option SHMConfig true in /etc/X11/xorg.conf. More precisely, a specific section for the touchpad must be created in xorg.conf. This section will include the appropriate option. According to /usr/share/doc/synaptics-0.14.6/INSTALL and to /usr/share/doc/gsynaptics-0.9.13/README, I added the following section:

Section "InputDevice"
  Identifier  	"Synaptics Touchpad"
  Driver  	"synaptics"
  Option 	"Device"  	"/dev/psaux"
  Option	"Protocol"	"auto-dev"
  Option        "SHMConfig"             "true"
EndSection
as well as this line to the "ServerLayout" section:
InputDevice "Synaptics Touchpad"  "AlwaysCore"
and restarted X.

It turned out that the setting provided by gsynaptics where very unsatisfactory. The speed setting for instance seems to be almost 0/1, i.e., very sloooow or way tooooo fast. Activating the vertical scrawling didn't work, etc. I think the problems might come partly from erroneous sizes settings for the touchpad. They have broken values by default, e.f., LeftEdge=1900!

Fortunately, the synaptics package comes with the synclient command line tool which saved my day. I rtfm (man synaptics and man synclient) and played some times to find satisfactory settings. Then I wrote the settings permanently in xorg.conf replacing the above InputDevice section by the following one:

Section "InputDevice"
  Identifier  	"Synaptics Touchpad"
  Driver  	"synaptics"
  Option 	"Device"  	"/dev/psaux"
  Option	"Protocol"	"auto-dev"
  Option        "SHMConfig"     "false"
  Option        "MinSpeed"      "0.7"
  Option        "MaxSpeed"      "1"
  Option        "AccelFactor"      "0.2"
  Option        "LeftEdge             "110"
  Option        "RightEdge            "970"
  Option        "TopEdge              "120"
  Option        "BottomEdge           "720"
  Option        "TapButton1"          "1"
 EndSection
Finding the right values for the edge coordinates was crucial to obtain a correct behavior of the touchpad. Launching synclient -m 100 starts a monitoring program of the touchpad that can be used to find the extremal values taken by the x and y coordinates during a standard use.

Sound

According to lspci, the audio device is a Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01). It is handled by the snd_hda_intel kernel module. I've not done any sophisticated testing or even thorough investigation, but the sound seems basically to work out of the box.

One annoying problem is that the pc beep is also activated by default, a pain for a laptop used in quiet places. The simplest way to shut forever the beep is to blacklist the corresponding kernel module (thanks to this blog post for pointing me to the solution). I've therefore added to /etc/modprobe.d/blacklist the following line:

blacklist pcspkr

Software

Fixed: Unison runs out of memory

It turns out that the behavior described below was a Fedora bug, as when unison was updated to unison227-2.27.57-9.fc9.1.x86_64 (the current version on my laptop), the memory problem disappeared.

This doesn't seem to be a Fedora related bug, but I never encountered it before: unison dies with an Out of memory error message during the synchronization of large repositories. The solution given in the Unison FAQ is to play with ulimit to increase the maximum stack size. I simply removed the limit via

ulimit -s unlimited
and unison resumed working.

Fixed (sort of): KDE is ugly

If you like KDE prepare yourself to a strong shock. Sulphur includes indeed KDE 4 in a quite ugly version, as shown on the following screen shot. Yes this is really ugly!

The graphical problem comes from the decorator used by gtk applications (on the screen shot, this is Firefox and NetworkManager). To solve this problem, install the gtk-qt-engine package.

yum install gtk-qt-engine
This provides new options in the System Settings of KDE (in Appearance), called GTK Styles and Fonts. They can be used to force the gtk applications to use the same style as KDE ones, leading to the following improved situation.

I still find that quite hideous, but it is at least consistent. Another problem it that KDE is localized in English, whereas I made a French install. A simple

echo $LANG
gives me as expected
fr_FR.UTF-8
but in KDE's System Settings (in Regional & Language), the only available option is Us English. A simple search of french in Yum Extender showed me that most of the french language packs were not installed on my system, in particular kde-i18n-French and kde-l10n-French. This was easily solved ;-) I also installed aspell-fr and openoffice.org-langpack-fr (which brought me aspell and aspell-en at the same time).

3D Desktop

KDE comes with a very easy to customize 3D Desktop. It is activated with System Settings (in Destkop). Effects can be chosen in the All Effects tab. Apart from the choice of keyboard short cuts which don't follow my personal taste, I find the effects easy to activate and to play with.

Unfortunately, this is not at all the same story for Gnome (with compiz).

Adapting to a laptop

A with Fedora 8, and this not specific to KDE, the default settings are not really adapted to a small screen (12 inches) as the one of the D430. As seen on the above screen shots, KDE's panel is huge and the fonts are also quite large for the screen.

R problems