My Thinkpad Status

ATI Radeon Mobility 9000

File: xorg.conf

(16.39 kb; Sun, Sep/25/2005)

I got both the radeonfb module as well as ATI's proprietary X driver fglrx working, but the latter is preventing me from safely suspending to disk (update: the newest versions are supposed to have preliminary suspend support, but I did not try that yet). Thus, I am using xorg's open source radeon driver, and everything is fine with that. (After all, I don't use OpenGL very often.) But I still have the configured fglrx "Device" section in my xorg.conf, it's just not used normally (i.e. not referenced in the "Screen" section). When I need hardware-accelerated OpenGL rendering, I simply change the reference to the Device "Radeon 250" in the Screen section to Device "Radeon 250 fglrx" and unload the radeon and drm kernel modules to allow the fglrx module to load.

See below for the X.org "Device" section I currently have in use.

With suspend-to-ram, my notebook suffered from a high power drain (around 5.7W!). That's a well known problem found on ThinkWiki and was attributed to the graphics card not being suspended. There is a script which checks if your notebook is affected, and the solution is to use a patched radeonfb driver (Update: The patch seems to have made it into the official kernel starting with version 2.6.18, so it's no longer needed). I am indeed using that now, and in contrast to my first experiences, it seems to be very stable with both suspend to disk and to ram. The power consumption went down to less than 400mW (additionally, I disabled wakeup-on-LAN with ethtool -s eth0 wol d), which means that the battery lifetime in ACPI sleep improved from the disappointing seven hours (with full battery!) to more than 110 (nearly five days). That's what I call satisfying. ;-)

Connecting an External Projector

Today, I tried to connect a 1024x768 beamer to my notebook. After all, I could already switch the resolution of my display from the supported 1400x1050 to any other with xrandr:

xrandr # displays supported resolutions
xrandr -s 2 # switches to 1024x768 for me

So, I figured it would probably boil down to xrandr -s 2 and connecting the device. Not much so! ;-) The image was totally distorted and ugly to the eyes.

The essence of my struggling is:

• There is a fine manpage describing the possible options for our radeon xorg driver: man radeon. I simply was not aware of that, and since it describes all options that I found mentioned in the WWW exactly, I just have to point you there, just in case.

• What was causing my problems, were some entries in the "Device" section of my xorg.conf which contained wrong hsync and vsync values. I simply removed them and rely on auto-detection now, which works just fine.

• The auto-detection works as follows: When X starts up, it first checks for the current MonitorLayout, i.e. what devices are

  connected, and then looks for their DDC information (cf. "display data channel" for reading monitor data via the VGA cable). There are two cases:

  1. If no external device is connected, I get the LCD (called LVDS by the radeon driver) as primary monitor, and NONE as Secondary. The LCD has a DVI_DDC type and decides on the valid frequencies. When I connect the external projector, it squirms, because the HSync/VSync are out of range.

  2. If I (re)start X with the projector connected, the internal LCD's DDC information is ignored (not even appears in the Xorg.0.log, but the DDC type becomes NONE), and the external devices information is read and used. Which gives me nice-looking output.

     The driver defaults to MergedFB mode (similar to Xinerama, but simpler and faster) and thus lets both devices display contents from the same shared framebuffer. By default, both look at the same "position", e.g. CRT2Position will be "Clone" (see the radeon manpage for details on this).

  A correct tip found in the internet is thus: Restarting X after connecting the external monitor will help in many cases.

  This is my relevant xorg.conf section:

  Section "Device"
      Identifier  "Radeon R250"
      Driver      "radeon"
      BoardName   "ATI Technologies Inc Radeon R250 Lf [FireGL 9000]"
      VendorName  "IBM Thinkpad"
  
      Option      "AGPFastWrite" "yes" # used only when DRI is enabled
  #   Option     "AGPMode" "4"         # only for DRI, crashes my Thinkpad
      Option      "DynamicClocks" "on" # increase battery life
  
      # I fixed the detected frequencies for our specific external
      # projector, which saves me from restarting X but I would have
      # to edit xorg.conf if I connected a too different device.
      # It's safe(r) to leave out these three lines:
      Option      "CRT2HSync"    "15-92"
      Option      "CRT2VRefresh" "50-85"
      Option      "MergedFB"     "on"
  
      # You can adjust which resolution pairs you want to have
      # available for primary and secondary monitor respectively.
      # It is checked that these are valid, available resolutions
      # and you can switch between them with [Ctrl][Alt][Kp+]/[Kp-]
      # as usual.
      Option      "MetaModes"   "1400x1050 800x600 1024x768 1280x1024 1400x1050-1024x768"
  EndSection
  
  Section "Monitor"
      Identifier  "LCD"
  
      # I commented these out to have proper auto-detection (see above):
  #   HorizSync   31.5 - 44
  #   VertRefresh 45 - 75
  
      # Let X calculate the correct DPI from these screen extents:
      DisplaySize 305 228 # (millimeter)
  
      Option  "DPMS"
  EndSection
  

Making NumLock work again

Having configured the above graphics modes, I still could not switch between resolutions with [Ctrl][Alt][Kp+]/[Kp-] (at least not within KDE) since I could not use the numlock key. This is because on my thinkpad, NumLock is [Shift][ScrollLock] and the standard XKB shortcut for mouse emulation is [Shift][NumLock] (AFAIK KDE enables the standard XKB accessibility features). So what happens is that NumLock is kind of toggled, but always together with the mouse emulation (xev shows Pointer_EnableKeys as the performed event, the NumLock LED stays off, and the "keypad" keys [j],[k],[l],... are moving the mouse), and I cannot use the [Kp+]/[Kp-].

With xmodmap -pke | grep Pointer I found out that the following command helps:

xmodmap -e "keycode 77 = Num_Lock"

(It simply takes away the second meaning for keycode 77 + Shift.)

Networking / Roaming

I managed to make network roaming work like a charm for me. You can find many pages telling you how to do so, often offering scripts of varying length, generality, and use, so I will just tell you how I did it:

• I am using the IPW2200 driver and wpa_supplicant for automatically setting up WLAN connections with WEP or WPA. For WPA, you need wpa_supplicant, so you can as well use it for everything else. It's a swiss army knife which comes with a well-documented example config file. These are the switches that are in effect in my config:

  ctrl_interface=/var/run/wpa_supplicant
  ctrl_interface_group=0
  eapol_version=1
  ap_scan=1
  fast_reauth=1
  
  # university network with WEP:
  network={
      ssid=".........."
      scan_ssid=1
      key_mgmt=NONE
      wep_key0="............."
      auth_alg=OPEN
  }
  
  # my dad's old WEP network:
  network={
      ssid=".............."
      scan_ssid=1
      key_mgmt=NONE
      wep_key0=..........................
  }
  
  # this is my home network with WPA:
  network={
      ssid=".............."
      #bssid=..:..:..:..:..:..
      psk="......................."
      key_mgmt=WPA-PSK
      proto=WPA
  }
  

  When wpa_supplicant successfully set up a connection, it will call /etc/init.d/net.eth1 start/stop which I hand-wrote to set up the right network parameters. In 99% of all cases, you would just use dhcpcd on the WLAN device (eth1 in my case).

  Caution!

  Note that with ipw2200-1.0.6 and the latest kernels, which support version 18 of the wireless extensions, you will get messages like:

  ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported
  

  This is due to ipw2200.c which explicitely disables that IOCTL for WE>=18; some comments indicate that it's "deprecated". The solution is to make it use the new, generic interface by using the wext (wireless extensions) backend instead of the ipw one:

  # -dd is only for debugging:
  wpa_supplicant -c/etc/wpa_supplicant.conf -Dwext -ieth1 -w -dd

• For ethernet cable connections, there is another daemon: ifplugd. This monitors cable (un-)plugging events and calls /etc/ifplugd/ifplugd.action (previously /usr/sbin/ifplugd.action) which in in turn calls /etc/init.d/net.eth0 start/stop by default, thus auto-configuring the ethernet connection. Since I am not using DHCP for some of my networks, I am using this special ifplugd.action script (of course, Y.Y.Y.Y is to be substituted with a real IP adress / gateway):

  #!/bin/sh
  
  if [ "$1" != "eth0" ]; then
      logger -t ifplugd.action "Error: Couldn't configure $1, device not handled [hlm]!"
      exit 1
  fi
  
  case "$2" in
      up)
          ifconfig $1 192.168.0.X up && \
          route add default gw 192.168.0.1 dev $1
          if ! ping -c 3 192.168.0.1 > /dev/null; then
              ifconfig $1 Y.Y.Y.Y up && \
              route add default gw Y.Y.Y.Y dev $1
              if ! ping -c 3 Y.Y.Y.Y > /dev/null; then
                  dhcpcd $1
              fi
          fi
          ;;
      down)
          dhcpcd -k $1
          ifconfig $1 0.0.0.0
          ;;
      *)
          echo "$0: wrong arguments"
          echo "Call with <interface> <up|down>"
          exit 1
          ;;
  esac

As you can see in the next section, I configured Fn-F3 to toggle the WLAN (note that you have to pass the -w cmdline switch to wpa_supplicant to make it wait for the device appearing). Thus, I can freely switch between WLAN and cable: When downloading something via WLAN, and I am not content with its speed, I walk over to the next cable and plug it it. Soon, I have a second route set up, and I can switch off WLAN with Fn-F3 (actually, I should give the cable a higher priority - stay tuned! ;-) ). The downloads in progress speed up without any connection breaking, and the same thing works the other way round, too! :-)

Global Key Bindings

File: acpi_default.sh	(2241 bytes; Wed, Aug/31/2005)
File: toggle_ipw2200	(396 bytes; Wed, Sep/28/2005)
File: .tpbrc	(216 bytes; Fri, Jan/06/2006)
File: ibm_button_callback	(68 bytes; Thu, Aug/25/2005)

Although I do not see the point of most of the extra keys on modern keyboards (like "WWW" or "Mail" keys which do not work under Linux), I put some effort into having sensible global shortcuts on my ThinkPad:

• Bluetooth is toggled with Fn-F5 (which carries the right symbol), and I let the notebook also setup a connection to my mobile phone automatically
• Similarly, suspend-to-ram/disk are bound to Fn-F4/F12 respectively
• WLAN is toggled with Fn-F3 (loads/unloads the driver)
• Since the "Access IBM" could only be accessed via tpb (an X program, at least when compiled with OSD support), I assigned the less-important and X-specific task of switching off the screen to it (i.e. /usr/bin/xset dpms force off)
• I setup tpb to have a nice OSD for the volume/brightness/ThinkLight keys

You might be interested in some of my config files (I most probably missed one, please tell me if so):

• /etc/acpi/default.sh which calls /usr/local/sbin/toggle_ipw2200

• ~/.tpbrc which uses /usr/local/bin/ibm_button_callback

  I modified /etc/X11/xdm/Xsetup_0 (to be specific, its equivalent $KDEDIR/share/config/kdm/Xsetup) to start tpb --daemon -c /home/<user>/.tpbrc. This has two advantages:

  • tpb is started very early, and you have an OSD as soon as X (and the graphical login manager) is started.
  • Starting tpb as root has the additional advantage that you can configure the granularity of the volume control, which is too coarse by default IMHO (although one might prefer to run it as nobody - sigh)

• Believe it or not, but I just noticed the two forward/backward keys near the cursor keys. ;-) You can map them to XF86Back/Forward using xmodmap. Just put this into your ~/.Xmodmap:

  # activate with 'xmodmap ~/.Xmodmap' if your system doesn't
  keycode 234 = XF86Back
  keycode 233 = XF86Forward
  

  In the Linux console, I use the following to make them switch between consoles (put into /usr/share/keymaps/i386/...):

  keycode 158 = Decr_Console
  keycode 159 = Incr_Console
  

  (Yes, I find it strange, too, that the right key has a lower X keycode than the left..)

My Kernel

Since I already mentioned that I am using suspend-to-disk, I want to share some information about the patched kernel I have running:

• Usually, I take the newest kernel from ftp://www.kernel.org/pub/linux/kernel/v2.6/ (At the time of writing, this is 2.6.17.6.)

  Note: Unfortunately, the latest kernels in conjunction with the latest ipw2200 drivers (1.1.3) caused me quite some hassle, compared with e.g. 2.6.13.2 and ipw2200-1.1.2. I am using separate releases of ipw2200 and ieee80211, carefully removing the in-kernel version of the latter before. I am tempted to stop doing so and use the versions shipped with the Linux kernel nowadays.

• Spock's framebuffer splash patches from http://dev.gentoo.org/~spock/projects/gensplash/current/ (or ../archive for other kernel versions)

• Software Suspend 2 from http://www.suspend2.net/downloads/

• The trackpoint driver patch (went into 2.6.14), see ThinkWiki (let's you configure e.g. tap-to-click and other parameters)

• The radeonfb patch fixing the high power drain during suspend (see above), taking the newest attachment from http://bugme.osdl.org/show_bug.cgi?id=3022 (no longer needed starting with kernel 2.6.18!)

This is the sequence of commands I used to unpack and patch my kernel:

tar xvjf linux-2.6.17.tar.bz2
rm -f linux && ln -s linux-2.6.17 linux
tar xvjf suspend2-2.2.7-for-2.6.17.tar.bz2
cd linux-2.6.17
../suspend2-2.2.7-for-2.6.17/apply
patch -p1 < ../fbsplash-0.9.2-r5-2.6.16.patch
patch -p1 < ../radeon-sleep.diff

File: config-2.6.13.2

(44.85 kb; Tue, Nov/22/2005)

You can download my kernel .config file, but note that I am using it for several computers, and that it's not very optimized e.g. for small size, but contains a lot of drivers not being used on my thinkpad (much hotplugging stuff, just in case I'll attach one of those devices some day ;-p ). However, it's definitely a working configuration.

Note that I am using the tpm_acmel TPM driver (which AFAIK is the successor of tpmdd which is the successor of IBM's research implementation), and the nsc-ircc driver for fast IRDA (don't load it by hand, configure irattach to start with nsc-ircc instead of e.g. /dev/ttyS0 as parameter).

I am using the following additional drivers:

• The IBM ACPI driver (providing software access to the hotkeys, leds, display/LCD configuration, ThinkLight, ...) - this has been in the kernel for quite some time already, and since 2.6.14, it even contains a newer version (0.12a), so I no longer compile a module externally.

• The APS (harddrive protection / acceleration sensor) driver from http://hdaps.sourceforge.net/ (which now also went into 2.6.14)

  At the time of writing, I have not yet setup a userspace daemon to actually park my harddrive's head. I only played a little bit with the driver and some test progs, e.g. "pivot" which displays the notebooks current orientation and "head_park" which parks the head - both work fine.

  Update: There now are a Gnome applet and an OpenGL app showing the current orientation. :-) http://primates.ximian.com/~rml/tilt/

• The IPW2200 driver: Even this is now in the infamous 2.6.14, alas only in version 1.0.0, which is quite old. This is why I use the separate 1.0.8 version from http://ipw2200.sourceforge.net/; the same goes for the ieee80211 subsystem which it depends on (i.e. I made sure that CONFIG_IEEE80211 is not set).

This is a list of the modules I let my system load at boottime:

• speedstep-centrino and cpufreq_conservative for dynamic CPU frequency scaling
• video, thermal, processor, ibm_acpi, fan, button, battery, and ac for ACPI features
• intel-agp, radeon for AGP graphics support (radeonfb is compiled into the kernel) - don't load radeon if you want to use fglrx, see above.
• snd-intel8x0 and snd-intel8x0m for sound and modem
• evdev, psmouse, and 8250_pci for mouse & serial devices
• ide-cd for the CD/DVD drive
• uhci-hcd and ehci-hcd for high-speed USB
• ohci1394 for OHCI-compliant FireWire support
• e1000 and yenta_socket for network & PCMCIA
• ieee80211_crypt_wep, ieee80211_crypt_ccmp, and ieee80211_crypt_tkip to let ipw2200 support wireless encryption modes when it is loaded later (see above)
• hdaps for the acceleration sensor
• tpm_atmel for the Trusted Computing chip

The Modem

Until recently, I had slmodem installed (the Smart Link modem driver), and the daemon would happily start, setup a modem device, and tell me about no problems. Even, when I eventually tried to actually use the modem, I did not see any problems, but I would always get a NO DIALTONE answer from the modem as a reply to a ATDT command. I found some postings reporting similar problems in the WWW, but with no solution.

Finally, I found out that it's simply the wrong driver! With those winmodems, where 90% of the modem is the driver, this can go unnoticed for quite some time, and at least in my case, I did not find any suspicious messages. For example, here's the syslog output when I tried the slamr module:

slamr: SmartLink AMRMO modem.
slamr: probe 8086:24c6 ICH4 card...
ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:1f.6 to 64
slamr: mc97 codec is CXT23
slamr: slamr0 is ICH4 card.

Some posting pointed to the scanModem shell script (available at the linmodems website), which is capable of identifying your modem. I found its output and the bunch of files it creates quite confusing, but at least it told me (after I found out that I have to run the unloading script before) that I obviously need the hsfmodem driver:

...
 The controller: 8086:24c6 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)1DB ICH4
 is capable of supporting soft modem chips from AT LEAST manufacturers:
...
Modem status     : PRA(GPIO) PRB(res) PRC(ADC1) PRD(DAC1) PRE(ADC2) PRF(DAC2) PRG(HADC) PRH(HDAC)
 Use a hsfmodem package from http://www.linuxant.com/drivers  for the Conexant soft modem.
 The modem has a Conexant codec: CXT
 and there support for the modem controller: 8086:24c6 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)1DB ICH4
...
  8086:24c6 is a Conexant HSF modem.
...

Unfortunately, the free version of the Linuxant driver does not support sending faxes, which is the only purpose why I would be interested in modem drivers at all. I would seriously consider spending $19 on the full version if I sent more than one fax a year though; the Linuxant people give very good reasons why they cannot offer a free driver and they seem to do a good job.

To summarize, this is c&p'ed wisdom from the scanModem output:

There are two mutually exclusive support possibilities:

1. The modem may have a Conexant chipset requiring supported by an hsfmodem package from http://www.linuxant.com/drivers.
2. Support through a low level ALSA modem driver, with intelligence provided by the slmodemd maintained by Sasha Kharposky.