Multiheading Linux Systems

How to use otherwise obsolete hardware to get a working Linux system on multiple displays.
Background

We used Red Hat 7.2 as the baseline because it has XFree86 4, which supports multiple displays (and input devices). Commercial X servers have supported this for a while, but XFree86 4 comes with new Linux distributions and it's free. Version 4 threw in a new configuration file and format to allow this flexibility. The key section is ServerLayout, which positions one screen relative to another. Here's an excerpt:

Section "ServerLayout"
        Identifier   "XFree86 Configured"
        Screen   0 "Screen0" 0 0
        Screen   1 "Screen1" LeftOf "Screen0"
        InputDevice  "Mouse0" "CorePointer"
        InputDevice  "Keyboard0" "CoreKeyboard"
EndSection

As you undoubtedly realize from this straightforward format, this setup will configure Screen0 (the screen associated with your primary video card) and then configure Screen1 and place it to the left of Screen0. In other words, you would move your mouse across Screen0, hit the left edge and then enter Screen1 from the right side (pretty confusing if you have the monitors backward). You can choose Right, Top, Bottom or even Relative positioning so the screens are diagonal. Do a man XFree86 to get the details. The screens don't have to be the same resolution or even the same color depth. Make one or both virtual if you want, though we didn't find this easy to use. Each screen in ServerLayout is composed of a Monitor reference and Device (video card) reference as shown below:

Section "Screen"
        Identifier "Screen0"
        Device   "Card0"
        Monitor  "Monitor0"
        SubSection "Display"
                Depth   8
                #Virtual         1024 768
        EndSubSection
EndSection
Here's the monitor and device sections to support Screen0:
Section "Monitor"
        Identifier  "Monitor0"
        VendorName  "GWY"
        ModelName  "311"
EndSection
Section "Device"
        Identifier "Card0"
        Driver   "mga"
        VendorName "Matrox"
        BoardName  "MGA 2164W"
        BusID    "PCI:0:14:0"
EndSection
The first key thing is to make sure everything is consistent, i.e., Screen0 has Monitor0 and Card0. What's important is that the names match, not what they are. We have developed a habit of making one set end in 0 and the next set end in 1, instead of keeping track of the card and monitor names. It's just easier to avoid mistakes.

The next key thing is the device driver. That gets identified by the XFree86 -configure step for both cards. Finally, it's critical to get the BusIDs straight. It's optional with only one card but mandatory for two or more. An AGP card will start with a 1, not a 0, and probably will be 1:0:0.

Now you have the basics and need to fine-tune /etc/X11/XFConfig-4 to get optimal performance. Edit this file and interleave the data identified in /root/XFConfig-4.new. Because we're using KDE's graphical login, you can tweak the file, log out, restart the X server from the KDE login window, do the login and see what happens. If you're not happy, tweak and repeat. It's much faster than manually restarting X. See Listing 1 [available at ftp.linuxjournal.com/pub/lj/listings/issue99/5958.tgz] for a full XFConfig-4 file.

At this point, you have a working multiheaded system utilizing the KDE graphical login and probably the KDE environment (Figure 1). It turns out that there are four different configurations that can be set up: GNOME or KDE login, and then the GNOME or KDE environment. We'll go through the advantages and disadvantages of each approach now.

Figure 1. Successful Multiheaded System in Action

Options

The file /etc/sysconfig/desktop determines which login manager is used. It's a one-line file saying DESKTOP="GNOME" or DESKTOP="KDE". Edit as root, according to your requirements. Here are the four configuration options:

  1. KDE login manager/KDE work environment (your system is set up this way if you followed the formula). This approach gives you two screens that can be identified by :0.0 for the primary and :0.1 for the secondary. The screens are separate, so you can't move windows from one screen to the other. You have a KDE menubar for each screen. The best use for this is to devote a screen to monitoring (error log, network activity, server room temperature, etc.) whatever you need to keep an eye on that takes up a lot of screen real estate. This is the original motivation for making this work—use some old hardware to monitor network activity and do other work without having another computer on the desk. Since we're working with Linux and have the X Window System, it's easy to control where the X applications appear. You could type DISPLAY=:0.1 (bash/ksh/sh syntax), and then your application will appear in screen :0.1. If you wanted to have just one well-behaved X application in the other screen, type xclock -display :0.0, for example.

  2. KDE login manager/GNOME work environment (type switchdesk from a command prompt and select GNOME to change from the original setup). This gives you a window manager controlling one screen and raw X on the other. You could type /usr/X11R6/bin/mwm -display :0.1 & in an xterm (ignore the warning) and get a different window manager running in the other screen. The commands twm and fvwm2 also will work. This is useful for testing purposes because you can quickly see if there are any problems with an application by running it in the environments. As in configuration one, the screens are separate.

Configurations three and four take a different approach and use the Xinerama extensions in XFree86 4. The authors are grateful to Dennis Baker for his splendid HOWTO. Xinerama makes one big screen, so it's probably the easiest and most natural way to work. You just move the windows from one screen to another. There are two key steps for these configurations. First, change the /etc/sysconfig/desktop file as above. Second, in the file /etc/X11/gdm/gdm.conf, edit the line 0=/usr/bin/X11/X toward the end of the file by making it read 0=/usr/bin/X11/X +xinerama.

  1. GNOME login/GNOME work environment with one large connected screen. When you maximize a window it will fill its screen.

  2. GNOME login/KDE work environment. (Select KDE from the login window if you just want to try KDE once.) Again, it's one large connected screen. This time when you maximize a window it fills the complete screen (spanning between screens).

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Multiheading Linux Systems

Anonymous's picture

I have a VisionTek xtasy 9200se video card which comes with two ports for two monitors on it, how can I use that instead of two video cards?

Re: Multiheading Linux Systems

Anonymous's picture

If anyone has new instructions on how to do this with RH8.0 please email me at kett00@charter.net, it doesnt work with 8.0

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix