next up previous contents index
Next: System Up: Configuration Previous: Hotplugging Services   Contents   Index


Configuring and Using Laptop Computers

Laptop computers have unique needs. These include Power Management (APM and ACPI), infrared interfaces (IrDA), and PC cards (PCMCIA). Occasionally, such components can also be found in desktop computers. These are essentially no different than those used in laptops. For this reason, their use and configuration is summarized in this chapter.


PCMCIA stands for ``Personal Computer Memory Card International Association.'' It is used as a general term for all hardware and software involved.

The Hardware

The essential component is the PCMCIA card. There are two distinct types:

PC cards
These are currently the most used cards. They use a 16-bit bus for data transmission, are usually relatively cheap, are generally stable, and are fully supported.

CardBus Cards
This is a more recent standard. It uses a 32-bit bus, which makes them faster, but also more expensive. Because the data transfer rate is frequently restricted at another point, it is often not worth the extra cost. There are now many drivers for these cards, although some are still unstable. This also depends on the available PCMCIA controller.

If the PCMCIA service is active, determine the type of the inserted card with the command cardctl ident. A list of supported cards can be found in SUPPORTED.CARDS in /usr/share/doc/packages/pcmcia. The current version of the PCMCIA-HOWTO is also located there.

The second necessary component is the PCMCIA controller or the PC card or CardBus bridge. This establishes the connection between the card and the PCI bus and, in older devices, the connection to the ISA bus as well. These controllers are almost always compatible with the Intel chip i82365. All common models are supported. The type of controller is shown with the command pcic_probe. If this is a PCI device, the command lspci -vt also shows some interesting information.

The Software

Differences Between PCMCIA Systems

There are currently two PCMCIA systems -- external PCMCIA and kernel PCMCIA. The external PCMCIA system by David Hinds is the older system, which makes it better tested. It is still being developed. The sources of the modules used are not integrated in the kernel sources, which is why it is called an ``external'' system.

From kernel 2.4, there are alternative modules in the kernel sources. These form the kernel PCMCIA system. The basic modules were written by Linus Torvalds. They support the more recent CardBus bridges better.

Unfortunately, these two systems are not compatible. There are various sets of card drivers in both systems. For this reason, only one system can be used, depending on the hardware involved. The default in SuSE Linux is the more recent kernel PCMCIA. It is possible to change the system, however. To do this, the variable <PCMCIA_SYSTEM> in the file /etc/sysconfig/pcmcia must be given either the value external or kernel. Then PCMCIA must be restarted with rcpcmcia restart. For temporary changes, use the commands rcpcmcia restart external or rcpcmcia restart kernel. If pcmcia is not running, use the option start instead of restart. Detailed information about this can be found in /usr/share/doc/packages/pcmcia/README.SuSE

The Base Module

The kernel modules for both systems are located in the kernel packages. In addition, the packages pcmcia and hotplug are required. When PCMCIA is started, the modules pcmcia_core, i82365 (external PCMCIA) or yenta_socket (kernel PCMCIA), and ds are loaded. In some very rare cases, the module tcic is required instead of i82365 or yenta_socket. They initialize the existing PCMCIA controller and provide basic functionality.

The Card Manager

Because PCMCIA cards can be changed while the system is running, a daemon to monitor the activity in the slots is required. Depending on the PCMCIA system chosen and the hardware used, this task is performed by the card manager or the hotplug system of the kernel. With external PCMCIA, only the card manager is used. For kernel PCMCIA, the card manager only handles PC Card cards. CardBus cards are handled by hotplug. The card manager is started by the PCMCIA start script after the base modules have been loaded. Because hotplug manages other subsystems apart from PCMCIA, it has its own start script. See also 7.

If a card is inserted, card manager or hotplug determines the type and function of the card then loads the corresponding modules. If this is successful, card manager or hotplug starts certain initialization scripts, depending on the function of the card, which in turn establish a network connection, mount partitions from external SCSI hard drives, or carry out other hardware-specific actions. The scripts for the card manager are located in /etc/pcmcia. The scripts for hotplug can be found in /etc/hotplug.

If the card is removed, card manager or hotplug terminates the various card activities using the same scripts. Finally, those modules that are no longer required are unloaded.

Both the start process of PCMCIA and card events are recorded in the system log (/var/log/messages). Here, it is specified which PCMCIA system is currently used and which daemons have been used by which scripts to set up things. In theory, a PCMCIA card can simply be removed. This works very well for network, modem, or ISDN cards as long as there are no open network connections. It does not work in connection with partitions mounted to an external hard drive or with NFS directories. Here, ensure that these units are synchronized and cleanly unmounted. This is no longer possible, of course, if the card has already been removed. In case of doubt, the command cardctl eject may be of help. This command deactivates all cards still in the laptop. To deactivate one card, also specify the slot number, for example, cardctl eject 0.


Whether PCMCIA or hotplug is started when booting can be specified with the YaST runlevel editor or on the command line using chkconfig. In /etc/sysconfig/pcmcia, there are four variables:

Specifies which PCMCIA system to use.

Contains the name of the module that addresses the PCMCIA controller. Normally, the start script detects this name on its own. The module is only entered here if this goes wrong. Otherwise, this variable should be left empty.

Intended for parameters for the module pcmcia_core. They are only rarely required, however. These options are described in pcmcia_core.

Parameters for the module i82365. Refer to i82365. If yenta_socket is used, these options are ignored, because yenta_socket has no options.

The assignment of drivers to PCMCIA cards for the card manager can be found in the files /etc/pcmcia/config and /etc/pcmcia/*.conf. First, config is read then the *.conf in alphabetical order. The last entry found for a card is decisive. Details on the syntax of these files can be found in pcmcia. The assignment of drivers to PCMCIA cards for hotplug is described in 7).

Network Cards (Ethernet, Wireless LAN, and Token Ring)

These can be set up with YaST like normal network cards. Select ` PCMCIA' as the card type. All other details about setting up the network can be found in the network chapter. Read the notes there about hotpluggable cards.


Even for ISDN PC cards, configuration is done to a large extent using YaST, as with other ISDN cards. It is not important which PCMCIA card offered there is chosen, but only that it is a PCMCIA card. When setting up hardware and provider, make sure the operating mode is set to hotplug and not to onboot.

ISDN modems also exist for PCMCIA cards. These are modem cards or multifunction cards with an additional ISDN connection kit. They are treated like an ordinary modem.


For modem PC cards, there are normally no PCMCIA-specific settings. As soon as a modem is inserted, it is available under /dev/modem.

There are also ``soft modems'' for PCMCIA cards. As a rule, these are not supported. If there are some drivers, they must be integrated individually into the system.


The corresponding driver module is loaded by the card manager or hotplug. When a SCSI or IDE card is inserted, the devices connected to it are available. The device names are detected dynamically. Information about existing SCSI or IDE devices can be found in /proc/scsi or /proc/ide.

External hard drives, CD-ROM drives, and similar devices must be switched on before the PCMCIA card is inserted into the slot. SCSI devices must be actively terminated.


Before a SCSI or IDE card is removed, all partitions on the devices connected must be unmounted. If you have forgotten to do this, you can only access these devices again after rebooting the system, even if the rest of the system continues to run in a stable manner.

You can also install Linux entirely on these external hard drives. However, the boot process is then somewhat more complicated.

A boot disk is required in all cases -- containing the kernel and an initial ramdisk (initrd). More information about this can be found in 11. The initrd contains a virtual file system that includes all required PCMCIA modules and programs. The boot disk and boot disk images are constructed in the same way. With these, you could always boot your external installation. It is, however, tiresome to load the PCMCIA support every time by hand. More advanced users might create their own boot floppy disk, customized to their own particular system. Hints for doing this can be found in the PCMCIA-HOWTO in the section Booting from a PCMCIA Device.

Switching Configurations -- SCPM

Often with mobile computers, various configuration profiles are required. With PCMCIA devices, this was never a problem, thanks to the PCMCIA schemes. Because the users of the built-in network cards or USB and firewire devices would also like to use different profiles for system configuration, there is, from SuSE Linux 8.0, the package SCPM (System Configuration Profile Management). For this reason, SuSE no longer supports the PCMCIA schemes. To continue to use these, the configuration must be modified by hand under /etc/pcmcia. We recommend using SCPM instead, because any part of the system configuration can be administered here -- not just the PCMCIA parts.


Occasionally, there are problems with certain laptops and certain cards when using PCMCIA. Most difficulties can be solved with little trouble, if you approach the problem systematically.


Because both external PCMCIA and kernel PCMCIA are available in parallel in SuSE Linux, consider one special feature when loading modules manually. The two PCMCIA systems use modules of the same name and are located in different subdirectories under /lib/modules/<kernelversion>. The subdirectories are named pcmcia for kernel PCMCIA and pcmcia-external for external PCMCIA. For this reason, the subdirectory must be specified when loading modules manually, either with insmod /lib/modules/<kernel version>/<subdirectory>/<file name of module> or with modprobe -t <subdirectory> <module name>.

First, find out if the problem is with the card or with the PCMCIA-based system. For this reason, always start the computer first without the card inserted. Only insert the card when the base system appears to function correctly. All meaningful messages are recorded in /var/log/messages. The file should therefore be viewed, with tail -f /var/log/messages while the necessary tests are made. In this way, the error can be narrowed down to one of the two following cases.

Nonfunctional PCMCIA Base System

If the system hangs when booting with the message PCMCIA: Starting services or other strange things happen, starting PCMCIA the next time the system is booted can be prevented by entering NOPCMCIA=yes at the boot prompt. To isolate the error further, the base modules of the PCMCIA system used are manually loaded.

These commands are used to do this:

earth :# modprobe -t <dir> pcmcia_core
earth :# modprobe -t pcmcia-external i82365 (for external PCMCIA) or
earth :# modprobe -t pcmcia yenta_socket (for kernel PCMCIA)

or, in very rare cases,
earth :# modprobe -t <dir> tcic


earth :# modprobe -t <dir> ds

The critical modules are the first two.

If the error occurs when pcmcia_core is loaded, the manual pages for pcmcia_core can help. The options described there can first be tested using modprobe. As an example, switch off the APM support for the PCMCIA module. In a few cases, there could be problems with this. Use the setting do_apm=0 to deactivate power management:

  modprobe -t <dir> pcmciacore do_apm=0

If the chosen option is successful, it can be written to the variable <PCMCIA_CORE_OPTS> in the file /etc/sysconfig/pcmcia:


Checking free IO areas can lead to problems in isolated cases if other hardware components are disturbed by this. Get around this with probe_io=0.

If several options should be used, they must be separated by spaces:

PCMCIA_CORE_OPTS=do_apm=0 probe_io=0

If errors occur when loading the module i82365, refer to i82365.

A problem in this context is a resource conflict -- if an interrupt, IO port, or memory area is occupied twice. Although the module i82365 checks these resources before they are made available to a card, sometimes just this check will lead to problems. Thus, checking the interrupt 12 (PS/2 devices) on some computers leads to the mouse or keyboard hanging. In this case, the parameter irq_list=<List of IRQs> can help. The list should contain all IRQs to use. For example, enter the command modprobe i82365 irq_list=5,7,9,10 or permanently add the list of IRQs to /etc/sysconfig/pcmcia:


In addition, there are /etc/pcmcia/config and /etc/pcmcia/config.opts. These files are evaluated by card manager. The settings made in them are only relevant when loading the driver modules for the PCMCIA cards. In /etc/pcmcia/config.opts, IRQs, IO ports, and memory areas can be included or excluded. The difference from the option irqlist is that the resources excluded in config.opts are not used for a PCMCIA card, but are still checked by the base module i82365.

Improperly Functioning or Nonfunctional PCMCIA Card

Here, there are basically three variations: the card is not detected, the driver cannot be loaded, or the interface made available by the driver is set up incorrectly.

Determine whether the card is managed by the card manager or hotplug. For external PCMCIA, card manager always takes control, for kernel PCMCIA, card manager manages PC card cards and hotplug manages CardBUS cards. Here, only card manager is discussed. Hotplug problems are discussed in 7.

  • Unrecognized Card
    If the card is not recognized, the message Unsupported Card in Slot x appears in /var/log/messages. This message means card manager cannot assign a driver to the card. To do this, /etc/pcmcia/config or /etc/pcmcia/*.conf are required. These files function as the driver database. This driver database can be easily extended if you take existing entries as a template. Find out, with the command cardctl ident, how the card identifies itself. More information about this can be found in the PCMCIA-HOWTO Section 6 and in pcmcia. After modifying /etc/pcmcia/config or /etc/pcmcia/*.conf, the driver assignment must be reloaded with the command rcpcmcia reload.

  • Driver Not Loaded
    One reason for this occurring is that a wrong assignment has been made in the driver database. This can happen, for example, if a vendor uses a different chip in an apparently unchanged card model. Sometimes there are also alternative drivers that work better for certain models than the default driver. In these cases, precise information about the card is required. It can also be useful here to ask a mailing list or the Advanced Support Service.

    Another cause is a resource conflict. For most PCMCIA cards, it is irrelevant with which IRQ, IO port, or memory area they are operated, but there are exceptions. First test only one card and, if necessary, switch off other system components, such as the sound card, IrDA, modem, or printer. The allocation of system resources can be viewed with the command lsdev (it is quite normal that several PCI devices share the same IRQ).

    One possible solution would be to use a suitable option for the module i82365 (see PCMCIA_PCIC_OPTS). Many card driver modules also have options. Find these using the command modinfo /lib/modules/<the correct pcmcia directory>/<driver>.o (the complete path is needed to locate the correct driver). There is also a manual page for most modules. rpm -ql pcmcia | grep man lists all manual pages contained in package pcmcia. To test the options, the card drivers can also be unloaded by hand. Again, ensure that the module is using the correct PCMCIA system.

    When a solution has been found, the use of a specific resource can, in general, be allowed or forbidden in the file /etc/pcmcia/config.opts. There is even room here for options for card drivers. If the module pcnet_cs should be operated exclusively with IRQ 5, for example, the following entry is required:

    module pcnet_cs opts irq_list=5

    One problem that sometimes occurs with 10/100-Mbit network cards is incorrect automatic identification of the transmission method. Use the command ifport or mii_tool to view and modify the transmission method. To have these commands run automatically, the script /etc/pcmcia/network must be individually adjusted.

  • Incorrectly Configured Interface
    In this case, it is recommended to check the configuration of the interface to eliminate rare configuration errors. For network cards, the dialog rate of the network scripts can be increased by assigning the value DEBUG=yes to the variable in /etc/sysconfig/network/config. For other cards or if this is of no help, there is still the possibility of inserting the line set -x into the script run by card manager (see /var/log/messages). With this, each individual command of the script is recorded in the system log. If you have found the critical part in a script, the corresponding commands can be entered in a terminal and tested.

Installation via PCMCIA

PCMCIA is already required for installation if you want to install via network or if the CD-ROM is operated via PCMCIA. To do this, start with a boot floppy disk. In addition, one of the module floppy disks is required.

After booting from floppy disk (or after selecting ` Manual Installation' booting from CD), the program linuxrc is started. Select ` Kernel Modules (Hardware Drivers)' ->` Load PCMCIA Module'. Two entry fields appear in which to enter options for the modules pcmcia_core and i82365. Normally, these fields can be left blank. The manual pages for pcmcia_core and i82365 are available as text files on the first CD in the directory docu.

SuSE Linux 8.2 is then installed with the external PCMCIA system. During the installation, system messages are sent to various virtual consoles. Switch to them using

+ function key.

During the installation, there are terminals on which commands can be run. As long as linuxrc is running, use console 9 (a very spartan shell). After YaST starts, there is a bash shell and many standard system tools on console 2.

If the wrong driver module for a PCMCIA card is loaded during installation, the boot floppy disk must be modified manually. This requires a detailed knowledge of Linux, however. When the first part of the installation is finished, the system is partially or completely rebooted. In rare cases, it is possible that the system will hang when the PCMCIA is started. At this point the installation is already at an advanced stage, so Linux can be started without PCMCIA using the boot option NOPCMCIA=yes, at least in text mode. See also 8. It is possible that you can change some settings for the system on console 2 before the first part of the installation is completed, so the reboot will run successfully.

Other Utilities

cardctl is an essential tool for obtaining information from PCMCIA and carrying out certain actions. In cardctl, find many details. Enter just cardctl to obtain a list of the valid commands.

There is also a graphical front-end for this program -- cardinfo, shown in Figure 8.1) -- with which the most important things can be controlled. For this to work, the package pcmcia-cardinfo must be installed.

Figure 8.1: The cardinfo Program

Additional helpful programs from the pcmcia package are ifport, ifuser, probe, and rcpcmcia. These are not always required. To find out about everything contained in the package pcmcia, use the command rpm -ql pcmcia.

Updating the Kernel or PCMCIA Package

If you want to update the kernel, you should use the kernel packages provided by SuSE. If it is necessary to compile your own kernel, the PCMCIA modules must also be recompiled. It is important that the new kernel is already running when these modules are recompiled, because various information is extracted from it. The pcmcia package should already be installed, but not started. In case of doubt, run the command rcpcmcia stop. Install the PCMCIA source package and enter

  rpm -ba /usr/src/packages/SPECS/pcmcia.spec

The new packages will be stored in /usr/src/packages/RPMS. The package pcmcia-modules contains the PCMCIA modules for external PCMCIA. This package must be installed with the command rpm -force, because the module files belong officially to the kernel package.

For More Information

For more information about specific laptops, visit the Linux Laptop home page at Another good source of information is the Moblix home page at As well as a lot of interesting information, also find a Laptop-Howto and an IrDA-Howto. In addition, there is also the article Laptops and Notebooks (PCMCIA) in the SuSE Support Database at

SCPM - System Configuration Profile Management

There are situations when a modified configuration of the computer system is required. This would mostly be the case for mobile computers that are operated in varying locations. It could, however, also be that a desktop system temporarily uses other hardware components or you simply want to experiment a little. In all these cases, returning to the original system should be made an easy task. It would be even better if this modification of the configuration could be easily reproduced.

Up to the present, there had only been a solution to this problem for PCMCIA hardware. Various configurations could be stored there in certain profiles. SCPM was developed from there, lifting the restriction to PCMCIA. The ``System Configuration Profile Management'' allows to keep an arbitrarily chosen part of the system configuration in customized profiles. It is like making snapshots of the system configuration that can be restored at any time and the framing can be deliberately chosen.

The main application is network configuration on laptops, but different network configurations also often require different settings of other services, such as e-mail or proxies. Then other elements follow, like different printers at home and at the office (even offices), a separate X server configuration for the video beamer at conferences, special power-saving settings for the road, or the differing time zone in the agency abroad. Increasing use of this tool leads to the continuous discovery of new requirements. Feel free to contact us and share your thoughts and ideas about SCPM with us. SCPM is based on a flexible framework in an effort to allow even server-based profile management. Please give your wishes, inspirations, and error descriptions via our web front-end at

Basic Terminology and Concepts

The following are some terms that are used across the rest of the SCPM documentation and in the YaST module.

  • The term system configuration means the complete configuration of the computer. It covers all fundamental settings, like the use of partitions, network settings, time zone selection, and keyboard mappings.

  • A profile, also called a configuration profile, is a state that has been preserved and can be restored at any time.

  • Active profile designates the profile last selected. This does not mean that the current system configuration corresponds exactly to this profile, because the configuration can be customized at any time.

  • A resource in the SCPM context is an element that contributes to the system configuration. This can be a file or a softlink including its metadata, like user, permissions, or access time. This can also be a system service that runs in this profile, but is deactivated in another one.

  • There are preconfigured resource sets for the most common application cases. The selection of such a resource set allows easy determination of which elements of the system configuration should be handled by SCPM. Customized resource sets can be also created at any time as needed. All profiles use the same set in the current stage of development of SCPM. A further development of profiles that handle different resources has, however, already been taken into account.

SCPM YaST Module and Additional Documentation

A YaST module serves as a graphical front-end to SCPM and is provided an alternative to the command line front-end. Because the functionality of both front-ends is substantially the same and the knowledge of the command line front-end is useful in many cases, only the latter is described here. The operation of the YaST module for SCPM becomes very easy in combination with the help texts provided there. The few differring features of the YaST module are mentioned where appropriate.

The most current documentation is always the info pages for SCPM. Read these with tools like Konqueror (with the command konqueror info:scpm) or emacs. On the console, use info or pinfo. Technical information is provided at /usr/share/doc/package/scpm. Running scpm without any arguments returns a command option summary.

Configuring SCPM

SCPM must be activated before it can be used. By default SCPM handles network and printer settings as well as the XFree86 configuration. If you need to manage special services or configuration files, you have to activate appropriate Resource Groups. In order to list the predefined Resource Groups you may use the list scpm list_groups. If you just want to see the already activated Groups, use scpm list_groups -a. These commands have to be issued as user root on the command line. Activation or deactivation of a group is done with the command scpm activate_group NAME or scpm deactivate_group NAME, where NAME has to be susbtituted by the relevant group name. All the Resource Groups may also be configured with the YaST profile manager.

Activate SCPM with scpm enable. When run for the first time, SCPM is initialized, which takes a few seconds. Deactivate SCPM with scpm disable at any time to prevent the unintentional switching of profiles. A subsequent reactivation simply resumes the initialization.

Creating and Managing Profiles

A profile named default already exists after SCPM is activated. Get a list of all available profiles with scpm list. This so far only existing profile is thus also the active one which can be verified with scpm active. The profile default is a basic configuration from which the other profiles are derived. This is why all settings that should be identicaly in all profiles should be made first. These modifications are then stored in the active profile with scpm reload. The profile default can however be arbitrarily used, renamed or deleted.

There are two possibilities to add a new profile. If the new profile (named work here) should be based on the profile default, create it with scpm copy default work. The command scpm switch work changes into the new profile, which can then be modified. Sometimes the system configuration was modified for special purposes that should be kept in a new profile. The command scpm add work creates a new profile by saving the current system configuration in the profile work and marking it as active. Running scpm reload then saves changes to the profile work.

Rename or delete profiles with the commands scpm rename x y and scpm delete x. For example, to rename work to project use scpm rename work project. Delete project with scpm delete project. Only the active profile cannot be deleted.

The available commands are:

scpm list
lists all available profiles

scpm active
returns the active profile

scpm add <name>
saves the current system configuration to a new profile and activates it

scpm copy <source> <destination>
copies a profile

scpm rename <source> <destination>
renames a profile

scpm delete <name>
deletes a profile

The YaST module only offers an ` Add' button. Pressing it opens a dialog in which to select whether an existing profile should be copied or the current system configuration should be saved. Use ` Edit' for renaming.

Switching Configuration Profiles

The command scpm switch work switches to another profile (the profile work, in this case). You can switch to the active profile to save modified settings of the system configuration. Alternatively, use scpm reload to do this.

When switching profiles, SCPM first checks which resources of the active profile have been modified. It then queries whether the modification of each resource should be added to the active profile or dropped. These questions only concern the profile being left.

SCPM then compares the current system configuration with the profile to which to switch. In the phase, SCPM evaluates which system services need to be stopped or restarted due to mutual dependencies or to reflect the changes in configuration. This is like a partial system reboot that concerns only a small part of the system while the rest continues operating without change.

It is only at this point that

  1. the system services are stopped
  2. all modified resources (usually configuration files) are written
  3. the system services are restarted

Advanced Profile Settings

You can enter a description to every profile that is displayed with scpm list. For the active profile it may be set with scpm set description ``text''. Provide the name of the profile for inactive profiles, for instance, scpm set description ``text'' work. It is sometimes desired to perform additional actions which are not (yet) provided by SCPM while switching from one profile to another. Up to four executable programs or scripts can be attached to the profile for this purpose. They are called in various phases of the switching process. These phases are:

prior to stopping services when leaving the profile
after stopping services when leaving the profile
prior to starting services when activating the profile
after starting services when activating the profiles

Switching from profile work to profile home thus proceeds as follows:

  1. The prestop action of the profile work is executed.
  2. The services are stopped.
  3. The poststop action of the profile work is executed.
  4. The system configuration is changed.
  5. The prestart action of the profile home is executed.
  6. The services are started.
  7. The poststart action of the profile home is executed.

These actions can also be attached with the command set by entering scpm set prestop <filename>, scpm set poststop <filename>, scpm set prestart <filename>, or scpm set poststart <filename>. The call must be made to an executable -- scripts must refer to the correct interpreter and must be executable at least for the superuser.

All additional settings entered with set can be queried with get. The command scpm get poststart, for instance, returns the name of the poststart call or simply nothing if nothing has been attached.

Such settings can be reset by overwriting with "". This means that the command scpm set prestop removes the attached prestop program.

All set and get commands can be applied to an arbitrary profile in the same manner as comments are added. For example, scpm get prestop <filename> work or scpm get prestop work.


These scripts or programs should not be modifiable by arbitrary users because they are executed with the rights of the superuser. It is recommended to make scripts only readable to the superuser because they can contain sensitive information. It is best to provide these programs with the permissions -rwx--- root root with the commands chmod 700 variablefilename and chown root.root <filename>.

Profile Selection during Boot

It is possible to select a profile during the boot process by providing the boot parameter PROFILE=<name-of-the-profile> at the boot prompt. In the boot loader configuration (/boot/grub/menu.lst), the option title reflects the name of the profile. For example:

File: The File /boot/grub/menu.lst

gfxmenu (hd0,5)/boot/message
color white/green black/light-gray
default 0
timeout 8

title work
   kernel (hd0,5)/boot/vmlinuz root=/dev/hda6 PROFILE=work
   initrd (hd0,5)/boot/initrd

title home
   kernel (hd0,5)/boot/vmlinuz root=/dev/hda6 PROFILE=home
   initrd (hd0,5)/boot/initrd

title road
   kernel (hd0,5)/boot/vmlinuz root=/dev/hda6 PROFILE=road
   initrd (hd0,5)/boot/initrd

Systems that still use LILO as the boot loader may use File 22 as an example.
boot = /dev/hda
menu-scheme = Wg:kw:Wg:Wg
timeout = 80
message = /boot/message

image = /boot/vmlinuz
label = home
root = /dev/hda6
initrd = /boot/initrd
append = "vga=0x317 hde=ide-scsi PROFILE=home"

image = /boot/vmlinuz
label = work
root = /dev/hda6
initrd = /boot/initrd
append = "vga=0x317 hde=ide-scsi PROFILE=work"

image = /boot/vmlinuz
label = road
root = /dev/hda6
initrd = /boot/initrd
append = "vga=0x317 hde=ide-scsi PROFILE=road"
Then you can select the desired profile at the boot prompt.

Common Problems and Solutions

In most cases, SCPM should function smoothly. There are however some pitfalls, which are described here.

SCPM is currently not able to survive a system update. The difficulty lies in the fact that, with a system update, the data stored in the profiles is not cleanly updated by the automatic mechanisms. SCPM then detects a system update and refuses to work. In this situation, you should get an error message from SCPM that contains your operating system installation changed/is unknown, read man page! In this case, reinitialize SCPM with scpm -f enbale. Your profiles, however, will be lost and you must set them up again.

Sometimes it can also occur that SCPM stops working during a switch procedure. This may be caused by some outside effect, such as a user abort, a power fault, another similar problem, or even an error in SCPM itself. In this case, an error message saying SCPM is locked appears the next time you start SCPM. This is for system safety, because the data stored in its database may differ from the state of the system. To solve this issue, delete the lock file with rm /var/lib/scpm/#LOCK then update your database with scpm -s reload. After this procedure, proceed as usual.

If you want to change the Resource Group Configuration of an already initialized SCPM, there is no real problem doing so. However, you must run scpm rebuild after adding or deleting groups. This adds new resources to all profiles and removes the deleted ones. The deleted ones are then lost to the system, which may cause problems if they are configured specifically in your profiles. The only exception is the current profile, because it is not touched by SCPM. If you reconfigure your system with YaST, you do not need to rebuild manually because YaST does it.

APM and ACPI -- Power Management

Power management requires correspondingly designed hardware and existing BIOS routines. Most notebooks and many modern desktop computers meet these requirements. The APM (Advanced Power Management) standard has generally been used so far for this. These are basically functions implemented in the BIOS of the computer. This is why power management does not work equally well on all devices. It is currently advisable to use APM on laptops with a functioning implementation of it. This is because there are manufacturers that dropped APM in favor of completely relying on the more recent ACPI (Advanced Configuration and Power Interface) standard. ACPI is, however, based on a more complex concept and requires a good cooperation of hardware manufacturers, BIOS programmers, and operating system experts. The Linux implementation of ACPI is still incomplete and therefore only partially usable. A substantial improvement in this matter can only be expected for the 2.6 kernel.

Power Saving Functions

While many of these functions are of general interest, they become really important in mobile environments. These functions are described below along with the systems on which they can be used.

This operating mode only turns the display off and in some systems throttles the processor load. Not every APM offers this function. This corresponds to the ACPI state S1.

Suspend (to memory)

The complete state of the system is written to random access memory (RAM) and the entire system is subsequently put to sleep. The computer consumes only very little power in this state, allowing battery power to span stretches of time between twelve hours up to several days. The advantage of this state is the ability to resume work at the same point within a few seconds without having to boot and load necessary applications first. It is sufficient with most modern devices to close the lid to suspend and to simply open to resume work. This corresponds to the ACPI state S3.

Hibernation (suspend to disk)

The computer can last for longer than a winter in this operating state (the term hibernation alludes to this), because the state of the system is completely written to hard disk and the system is subsequently turned off. Resuming from hibernation takes between half a minute and one and a half minutes and the state upon suspension is likewise completely restored. Some manufacturers offer sensible hybrid variations of this mode (for instance, RediSafe in IBM Thinkpads). Hibernation corresponds to the ACPI state S4. Linux also offers a pure software solution, which, however, is not included in SuSE Linux. Information is available at

Monitoring the state of the battery

Apart from monitoring the charge status, it is equally important to take appropriate action when the power reserves run out. This is also handled by the BIOS APM routines in most cases. The apmdacpid or klaptopdaemon can be alternatively used for this.

Automatic power-off

The computer is completely turned off following a shutdown. This is especially of importance when an automatic shutdown is executed shortly before the battery runs out.

Shutdown of system components

The substantial component for conserving power is the hard disk, which can be spun down for a shorter or longer amount of time depending on the reliability of the whole system. However, the risk of a loss of data rises with the duration of the rest periods. Other components can be deactivated via ACPI (at least theoretically) or permanently in the BIOS setup. The infrared port should, where applicable, be deactivated for as long as its services are not required (see 8).

Processor speed control

APM generally only offers the possibility to select from various settings in the BIOS setup. Special tools are available for controlling hardware-specific settings on some devices, such as tpctl and apmiser from the package tpctl for IBM Thinkpads. The processor speed can be controlled with the procspeed application from the package apmd. The processor speed can only be influenced directly with ACPI. Therefore, these possibilities are covered in the ACPI section.


Some of the power saving functions are executed by the APM itself. Standby and suspend can be activated with key combinations or by closing the lid on many laptops. There is, at first, basically no need for contribution to this on part of the operating system. Corresponding packages and a suitable kernel must be installed if it is desired to invoke these functions by command, if it is necessary to execute certain actions before suspension, or to simply check the battery level.

APM support is integrated in the precompiled kernels of SuSE Linux. However, it is only activated if ACPI is not implemented in the kernel and an APM BIOS is detected. The APM support can be activated at the boot prompt with acpi=off. The command cat /proc/apm can be used to check if APM was activated. Everything is in order if a line containing various numbers is returned. Now, the command shutdown -h should shut down the computer.

Spurious behavior can occasionally arise from some incompletely compliant BIOS implementations. Some problems can be circumvented with special boot parameters, which previously were kernel configuration options. All parameters are entered at the boot prompt in the form apm=<parameter>:

on or off
activate or deactivate APM support

Allow interrupts during the execution of BIOS functions

The BIOS has a broken ``GetPowerStatus'' function

Reset the processor to ``real mode'' before shutdown

Log APM events in the system log.

Power off the system after shutting down.

Blackout time in 1/100ths of a second following a suspend event during which additional suspend events are ignored.

Percentage of system activity under which the BIOS function idle is called (0=always, 100=never)

Period of time in hundredths of a second during which the system activity is evaluated

The APM Daemon (apmd)

The apmd daemon monitors the battery and can invoke certain actions when a standby or a suspend event occurs. It is located in the package apmd. It is not indispensable for operation, yet can be helpful for some problems.

apmd is not started automatically on boot. The settings for the system services, however, can be modified with the YaST runlevel module if necessary. The chkconfig utility can alternatively be used. The service can be called manually with the command rcapmd start.

A few configuration variable are present in /etc/sysconfig/powermanagement. Only a few hints are provided here because the file is commented.

This determines that the behavior of the hard disk follows the state of power supply. There is a also series of other variables that either begin with APMD_BATTERY or APMD_AC. The former contain settings for the operation with battery power, the latter for the operation with external power supply.

After how long a period of disk inactivity should it be spun down. The values are described in 8 or in the man page of hdparm, option -S.

The time between runs of the kernel update daemon.

The maximum age of buffered data.

The maximum fill level of the hard disk buffer.

Problems sometimes occur despite PCMCIA being compiled into kernels with APM support. Some of the card drivers do not resume correctly from a suspend (xirc2ps_cs). This is why apmd can deactivate the PCMCIA system prior to a suspend and can reactivate it afterwards. The variable APMD_PCMCIA_EJECT_ON_SUSPEND is set to yes for this.

Network interfaces that should be stopped prior to a suspend and started afterwards can be entered here.

This variable should be used if the driver modules of the interfaces mentioned before should equally be unloaded.

It is also sometimes the case that resuming from a suspend does not work if an IDE device (hard disk) remained in DMA mode.

Furthermore, there are additional options, like for adjusting the key repeat rate or the system clock after a suspend or for shutting down the laptop properly when the APM BIOS sends a ``battery critical'' event. The script /usr/sbin/apmd_proxy, which performs the jobs described above, can be adjusted to any requirements for even more specialized actions.

Further Commands

package apmd contains a few additional handy utilities. The utility apm checks and returns the current battery charge level or puts the system into standby (apm -S) or suspend (apm -s) mode. Refer to apm.

The command apmsleep suspends the system for a given time.

tailf can be used instead of tail -f to watch a log file without preventing the hard disk from spinning down.

There are of course also tools for the X Window System. The package apmd also contains the xapm utility for displaying the charge level of the battery. The kbatmon applet displays the charge level of the rechargeable battery to users of the KDE desktop and can also suspend the system. The xosview monitoring utility is likewise interesting as an alternative.


ACPI is the abbreviation for Advanced Configuration and Power Interface. ACPI is designed to enable the operating system to configure and control the individual hardware components. Accordingly, ACPI supersedes both PnP as well as APM. The part of ACPI responsible for initializing the hardware is not covered in this chapter. Additionally, there is little to do for the user in this regard.

The BIOS provides tables containing information about the individual components and methods for the access to the hardware. This information is used by the operating system for tasks such as assigning interrupts or activating or deactivating components as needed. However, as operations performed by the operating system perform operations integrated in the BIOS, the functionality depends on the BIOS implementation. The boot messages are logged to /var/log/boot.msg. Here ACPI reports which tables it was able to find and read.

Differentiated System Description Table: Contains information about the components of the computer and how these can be configured.
Fixed ACPI Description Table: Contains information about the implementation of the ACPI hardware register block and the physical address of the DSDT.
Multiple APIC Description Table: Describes the implementation and configuration of the APIC.
Root System Description Table: Table containing pointers to the other tables. The pointer to the RSDT (RSDP) must be located in the low memory range.
Secondary System Description Table: This table is a continuation of the DSDT. There can be several SSDTs. The distribution to several tables increases the flexibility especially for OEM.
Extended Root System Description Table: Contains the same information as RSDT, but can also accommodate pointers to description headers larger than 32 bits. Alternatively, the RSDP can also point to the XSDT.

The ACPI standard defines a variety of system states. The main states are as follows:

System working
System sleeping, change to G0 without booting the OS (suspend)
Soft-off, OS must boot when switched on
Mechanical off, system is without power (mechanical main switch is off)
Furthermore, there are six sleep states that further distinguish G0, G1, and G2:
System working
Standby (less power consumption, rapid wake-up)
Another type of standby that is rarely implemented in devices.
Suspend (very low power consumption, rapid wake-up).
Hibernation or suspend to disk (no power consumption, wake-up takes a little longer -- twenty to one hundred seconds, depending on the hardware).
Soft-off (G2)

Furthermore, the states D0-D3 are available for all hardware components. In these states, the individual components are active, suspended, or off. There are special states for specific operational situations only known to the processor. The C states are introduced by CPU commands and cannot be influenced directly:

Processor working
Processor issues special low power instructions that consume less energy but allow rapid return to working state.
Like C1, with even less power consumption but longer wake-up time.
Like C2, even more savings, but the first-level cache is rendered inconsistent (only implemented in few devices and rarely used).
The performance states are associated with special processor technologies, such as Speedstep (Intel) or PowerNow (AMD), and involve changes in the clock frequency and the CPU core voltage:
Maximum clock frequency and core voltage
First saving stage, reduced frequency and voltage
Next saving stage (if available)
The third possibility to give the processor some rest is throttling. In this approach, the clock signal of the CPU is interrupted temporarily.
0% clock throttling
12% clock throttling
25% clock throttling
The P and T states can be set directly by the user (or a daemon). The main difference is the level of energy saving. Throttling merely yields linear savings, e.g., 25% clock throttling corresponds to 25% less performance and 25% less energy consumption (only for the processor). In contrast, the energy savings due to a performance change resulting from the reduced core voltage exceed the performance loss. The performance cutback is also used for ``passive cooling'', unlike the active cooling by means of the fan. It is also meaningful if you want to charge the battery quicker while you are using the computer.

In addition, ACPI provides information about the battery, AC adapter, temperature, and fan. It also reports system events such as ``close lid'' or ``low battery''.

ACPI in Action

If the kernel detects an ACPI BIOS when the system is booted, ACPI is activated automatically (and APM is deactivated). The boot parameter acpi=on might be necessary for some older machines. The computer must support ACPI 2.0 or later. Check the boot messages of the kernel in /var/log/boot.msg to see if ACPI was activated. In this case, there is also a directory /proc/acpi, which will be described later.

Then a number of modules must be loaded for OSPM ( ``Operating System Power Management''). These are loaded by the start script of the ACPI daemon. If any of these modules causes problems, it can be excluded from the loading or unloading process in /etc/sysconfig/powermanagement. The system log (/var/log/messages) contains the messages of the modules. Here, see which components were detected.

In /proc/acpi, you will now find a number of files that provide information on the system state or which can be used to actively change some states. However, many features do not work yet, either because they are still under development or because they are not implemented by the manufacturer.


To date, neither suspend to RAM or suspend to disk (hibernation) work with ACPI. Due to kernel-specific reasons, these features will only be available starting with kernel 2.6 (or kernel 2.5). If you think you can do it, you can integrate the sw-susp patch in your kernel.

All files (except dsdt and fadt) can be read with cat. In some of the files, settings can be modified by using echo X > file to specify suitable values for X (all objects in /proc are not real files on the hard disk but an interface for the kernel). Here is a description of the most important files:

General information about ACPI
Here, specify when the system should wake from sleep. The time is set with echo year-month-day hour:minute:second > /proc/acpi/alarm. However, as the sleep states do not work yet, it is folly to set an alarm.
Provides information about the possible sleep states. In the future, it will be possible to actuate a suspend here. Currently, the only states that might work are S1 (standby) and S5 (off, off immediately, no clean shutdown): echo 1 > /proc/acpi/sleep.
All events are reported here. These are processed by a daemon, such as 'acpid' or 'ospmd'. If no daemon accesses this file, the events can be read with cat /proc/acpi/event (terminate with + C). A brief click on the power button or closing the lid are some of these events.
/proc/acpi/dsdt and /proc/acpi/fadt
These files contain the ACPI tables DSDT and FADT. These files can be read with acpidmp, acpidisasm, and dmdecode. These programs and their documentation are located in the package pmtools. Example: acpidmp DSDT | acpidisasm.
Is the AC adapter connected?
Detailed information about the battery state. To read the battery charge level, last full capacity from info is compared with remaining capacity from state. This can be done more conveniently with special programs. The charge level at which a battery event is triggered can be specified in alarm.
This directory contains information about various switches.
Shows if the fan is currently active. It can also be switched on and off manually by writing 0 (on) or 3 (off) into this file. However, both the ACPI code in the kernel and the hardware (or the BIOS) overwrite this setting when it gets too warm.
Information about the energy saving possibilities of the processor.
Information about the current processor state. An asterisk next to C2 indicates that the processor is idle. This is the prevailing state, as you can see from the figure for usage.
Here you can read or set the performance -- use the Speedstep or PowerNow capabilities of the CPU.
This file enables further linear throttling of the processor.
If performance and throttling are automatically controlled by a daemon, the limits that should not be exceeded can be specified here. There are limits defined by the system and a user-definable limit. With echo 1:5 > /proc/acpi/processor/CPU0/limit, prevent the states P0 or T0-T4 from being used.
There is a subdirectory for each thermal zone. A thermal zone is an area with similar thermal properties whose number and names are selected by the hardware manufacturer. However, many of the possibilities offered by ACPI are rarely implemented. Rather, the temperature control is handled in the conventional way directly by the BIOS. The operating system is not given much opportunity to intervene, as the life span of the hardware is at stake. Therefore, the some of the following descriptions only have a theoretical value.
The current temperature of the thermal zone.
The states indicates if everything is ``ok'' or if ACPI uses ``active'' or ``passive'' cooling. Everything is ``ok'' in the case of ACPI-independent fan control.
Here, select the preferred cooling method under full ACPI control, either passive (less performance, but very economical) or active (always full performance and uninterrupted fan noise).
Here, determine the temperature at which something like passive or active cooling, a suspend (``hot''), or a shutdown (``critical'') should be actuated.
If the value in ``temperature'' is not updated automatically as soon as the temperature changes, switch to ``polling mode'' here. The command echo X > /proc/acpi/thermal_zone/*/polling_frequency causes the temperature to be queried every X seconds. Set X=0 to deactivate the ``polling''.

The ACPI Daemon (acpid)

The ACPI daemon processes events similarly to the APM daemon. These are currently merely some switching events, like the operation of the power button or the closing of the lid. All events are logged in the system log. The variables ACPI_BUTTON_POWER and ACPI_BUTTON_LID contain instructions for these events. The script /usr/sbin/acpid_proxy can be modified as well as the configuration of the acpid utility in /etc/acpi/ for more control options.

Unlike apmd, little is preconfigured here, as ACPI in Linux is still in a very dynamic development stage. If necessary, configure acpid yourself. If you have any suggestions on preparatory actions, please send an e-mail to

Speedstep of PowerNow

CPUs for mobile devices have the possibility to adjust the processor frequency to the current system demands. The system interface to this technology is available outside the ACPI subsystem. In /proc/cpufreq, read the current frequency and adjust it in /proc/sys/cpu/0/speed*. More information is available in /usr/src/linux/Documentation/cpufreq/.

To adapt the CPU frequency automatically, use the cpufreqd daemon. This is not started by default. More information about starting system services is available in Section 12. The documentation for cpufreqd is found in /usr/share/doc/packages/cpufreqd/README.SuSE and in the manual page (man cpufreqd). All system settings are configured in /etc/sysconfig/powermanagement.


There are two different types of problems. On one hand, there might be error in the ACPI cord of the kernel that was not detected in time. In this case, a solution will be made available for download. On the other hand, there might be problems in the BIOS of a computer. This happens more often and is more annoying. Unfortunately, deviations from the ACPI specifications are sometimes purposely integrated in the BIOS to circumvent errors of the ACPI implementation in other widespread operating systems. Hardware components that have serious mistakes in the ACPI implementation are recorded in a blacklist to prevent the Linux kernel from using ACPI for these components.

If you encounter a problem, the first thing you should do is update the BIOS. This will solve many problems. If the computer does not boot properly, one of the following boot parameters may be helpful:

Do not use ACPI for configuring the PCI devices.
Only perform a simple resource configuration. Do not use ACPI for other purposes.
Disable ACPI.

Another important step is to take a closer look at the boot messages. To do this, use the command dmesg | grep -2i acpi (or all other messages, since the problem may be due to something else than ACPI) the computer has booted. If an error occurs with the parsing of an ACPI table, at least the most important table -- the DSDT -- can be replaced by integrating an improved table in an individual kernel. This will cause the faulty DSDT of the BIOS to be ignored. However, this is not a simple task and requires some assistance by an expert. Bug-fixed DSDTs are available on the Internet for some computers.

For the kernel configuration, there is a switch that activates ACPI debug messages. If you compiled and installed a kernel with ACPI debugging, experts looking for an error can be supported with detailed information.

If you experience BIOS or hardware problems, it is always advisable to contact the manufacturer of the device. Although the manufacturers may not always be able to provide assistance for Linux, it is still important that they hear the word ``Linux'' as often as possible. The manufacturers will only take it seriously if they realize that an adequate number of their customers utilize Linux. Of course you can also contact the manufacturer to tell him that you use Linux on the hardware without any difficulties.

Additional documentation and help is available in the following sources:

Rest for the Hard Disk

An idling hard disk can be spun down in Linux. The hdparm utility serves the purpose of modifying various settings of a hard disk. The -y option puts the hard disk instantly into standby mode and the -Y option turns it off completely. The command hdparm -S <x> results in the hard disk spinning down after a certain time of inactivity. The <x> variable has a nonlinear scale: 0 turns the mechanism off and the hard disk runs continuously. Values between 1 and 240 are multiplied by five seconds. Values between 241 and 251 correspond to one to eleven times thirty minutes.

One problem is the number of processes in Linux that write to the hard disk, continuously waking it up. It is hence important to understand how Linux handles data that is supposed to be written to the hard disk.

All data is first written into a buffer in random access memory. This buffer is watched by the kernel update daemon kupdated.The buffer is flushed to the hard disk every time the data reaches a certain age or the buffer becomes filled to a certain degree. The size of the buffer is dynamic and depends on the size of the memory and the system load. kupdated is set by default to small time intervals because the preservation of data integrity is a primary goal. It checks the buffer every five seconds and informs the bdflush daemon when data is older than thirty seconds or the buffer is filled by more than thirty percent. The bdflush daemon then writes the data to the hard disk. It also writes independently of kupdated, for instance, when the buffer is full. Operators of a stable system can modify these settings. They must, however, be aware that this is done by risking data corruption.

The settings can be read with cat /proc/sys/vm/bdflush. The first value is the the flushing threshold of the buffer. The sixth value is the maximum age limit for buffered data in hundredths of a second. The fifth value is the checking interval for kupdated and is likewise given in hundredths of a second. For instance, to increase the kupdated interval to one minute, the new values are entered into this file with

echo 30 500 0 0 6000 > /proc/sys/vm/bdflush

The unchanged values are simply copied from the output and the trailing values can be omitted. Thus, entering

echo 60 > /proc/sys/vm/bdflush

changes the flushing threshold of the buffer to sixty percent. The remaining values are described in the file Documentation/filesystems/proc.txt of the kernel sources.


Changes to the settings of the kernel update daemon influence data intergrity. If in doubt, leave them be.

The settings for the hard disk time-out, the kupdated interval, the buffer threshold, and the maximum age of data can be duplicated in /etc/sysconfig/powermanagement: one set for battery operation and one set for external power supply. The variables are described in the section about apmd and within the file itself. ``Journaling file systems'', like reiserfs or ext3, write their metadata independently of bdflush, which prevents the hard disk from spinning down. At the time of writing, ext3 and jbd respect the fifth value of /proc/sys/vm/bdflush and also write their metadata less often if this value were raised. This is not yet the case for reiserfs. It is best to rely on the ext2 file system in cases of doubt.

It is necessary to observe how any used applications behave. Good text editors, for instance, regularly keep hidden backups of the currently changed file on disk. This will repeatedly wake up the hard disk. Such program features can also be turned off, but this endangers data integrity.

IrDA -- Infrared Data Association

IrDA (``Infrared Data Association'') is an industry standard for wireless communication with infrared light. Many laptops sold nowadays are equipped with an IrDA compatible transceiver that enables communication with other devices, such as printers, modems, LANs, or other laptops. The transfer speed ranges from 2400 bps up to 4 Mbps.

There are two IrDA operation modes. The standard mode SIR accesses the infrared port through a serial interface. This mode works on almost all systems and is sufficient for most requirements. The faster mode FIR requires a special driver for the IrDA chip. There are not, however, such drivers for all chips. The desired mode additionally must be set in the BIOS setup of the computer. This is also where it can be determined which serial interface is used for the SIR mode.

Information about IrDA can be found in the IrDA how-to by Werner Heuser at and on the web site of the Linux IrDA Project


The necessary kernel modules are included in the kernel package. The package irda provides the necessary helper applications for supporting the infrared interface. The documentation can be found at /usr/share/doc/packages/irda/README after the installation of the package.


The IrDA system service is not started automatically by the booting process. Use the YaST runlevel module to change the settings of the system services. The application chkconfig can be used alternatively. IrDA unfortunately consumes noticeably more battery power, because a ``discovery packet'' is sent every few seconds to detect other peripheral devices automatically. This is why IrDA should only be started when needed. The interface can always be activated manually with the command rcirda start or deactivated with the stop parameter. All necessary kernel modules are automatically loaded when the interface is activated.

The file /etc/sysconfig/irda contains only the one variable <IRDA_PORT>. This is where the interface used in SIR mode is set. The script /etc/irda/drivers of the infrared support package sets this variable.


Data can be sent to the device file /dev/irlpt0 for printing. The device file /dev/irlpt0 acts just like the normal /dev/lp0 cabled interface except the printing data is sent wireless with infrared light.

Printers used with the infrared interface are installed just like printers connected to the parallel or serial ports. Make sure the printer is in visible range of the infrared interface and the infrared support is started.

Communication with other hosts and with mobile phones or other similar devices is conducted through the device file /dev/ircomm0. The Siemens S25 and Nokia 6210 mobile phones, for instance, can dial and connect to the Internet with the wvdial application using the infrared interface. A data synchronization with a Palm Pilot is equally possible in this way when the device setting of the corresponding application has been set to /dev/ircomm0.

Only those devices can be accessed without any other adjustments that support the printer or IrCOMM protocols. Devices that support the IROBEX protocol, such as the 3Com Palm Pilot, can be accessed with special applications like irobexpalm and irobexreceive. Refer to the IR-HOWTO on this subject. The protocols supported by the device are stated in brackets behind the name of the device in the output of irdadump. IrLAN protocol support is still a ``work in progress'' -- it is unfortunately not stable yet but will surely also be available for Linux in the near future.


The superuser SuSE @nohyphen root can check with the command irdadump whether the other device has been recognized by the system in case devices do not work at the infrared interface.

Something similar to Output 14 appears regularly when a Canon BJC-80 printer is in visible range of the computer:

Output: IrDA: irdadump

21:41:38.435239 xid:cmd 5b62bed5 > ffffffff S=6 s=0 (14)
21:41:38.525167 xid:cmd 5b62bed5 > ffffffff S=6 s=1 (14)
21:41:38.615159 xid:cmd 5b62bed5 > ffffffff S=6 s=2 (14)
21:41:38.705178 xid:cmd 5b62bed5 > ffffffff S=6 s=3 (14)
21:41:38.795198 xid:cmd 5b62bed5 > ffffffff S=6 s=4 (14)
21:41:38.885163 xid:cmd 5b62bed5 > ffffffff S=6 s=5 (14)
21:41:38.965133 xid:rsp 5b62bed5 < 6cac38dc S=6 s=5 BJC-80
                        hint=8804 [ Printer IrCOMM ] (23)
21:41:38.975176 xid:cmd 5b62bed5 > ffffffff S=6 s=* erde
                        hint=0500 [ PnP Computer ] (21)

Check the configuration of the interface in case there is no output or the other device does not reply. Verify that the correct interface is used. The infrared interface is sometimes located at /dev/ttyS2 or at /dev/ttyS3 and another interrupt than IRQ 3 is used sometimes. These settings can be checked and modified in the BIOS setup menu of almost every laptop.

A simple CCD video camera can also help in determining whether the infrared LED lights up at all. Most video cameras can see infrared light, whereas the human eye cannot.

next up previous contents index
Next: System Up: Configuration Previous: Hotplugging Services   Contents   Index
root 2003-11-05