Multiheading Linux Systems
Engineering today requires a lot of screen real estate. When you start doing circuit layouts, math models and simulations, image processing and other engineering work, you need room. Plotting the results from two data runs with a package like octave is a common task and is difficult without adequate screen room. We have reached the point where using multiple monitors is pretty much the required baseline in order to work.
Fortunately, the rapid obsolescence of computer hardware has resulted in the early retirement of otherwise good equipment. Who doesn't have an extra video card or monitor lying around that was state of the art a few years ago but has been passed by now? Even if you don't, it doesn't cost much to pick up some new hardware and really spice up your system.
We present a formula to set up a Linux system to have two or more displays in various configurations, some lessons we learned while doing this and some uses we've found for the system. Be forewarned—following this formula doesn't guarantee success because some video cards just won't work with others. As always, please do the appropriate backups before making any system changes.
To set up your system for multiple cards, start with Red Hat 7.2, two video cards and monitors. We begin with a fresh install so you can see each of the steps in case you've already heavily modified your system. (Follow the spirit of these steps if you aren't using Red Hat 7.2 or if you are modifying a working installation.) Again, back up your data before trying any of this.
Physically install both video cards in the system, turn on both monitors and start the Linux installation.
Choose KDE and graphical login when you get to the appropriate part of the installation. This isn't crucial but makes things easier for testing and can be changed later.
Finish the installation and make sure your basic system and the X Window System are working by rebooting and logging in. At this time, you'll have one video card and monitor working.
As root, launch an xterm and make sure you're in your home directory by typing cd. Then type cp /etc/X11/XFConfig-4 . to create a backup copy of your X configuration file in your home directory, just in case.
Now, type telinit 3 to switch from runlevel 5, which uses a graphical login, to runlevel 3 with its console login.
Time to gather some data and see if this is going to work. Log in again as root. Type X -version and note the output. Buried in the output somewhere it will probably say 4.1.0 but could say 3.3.6a, depending on your primary video card. Next is the big step. Type XFree86 -configure and wait for the minute or so that this normally takes to run. Now type XFree86 -xf86config /root/XF86Config.new. If you are successful, you'll hear clicks from both monitors as they switch modes, and the power lights will switch from amber to green. The screens themselves will fill with the raw X display. If they do, congratulations, you should be able to make this setup work (note: kill X by pressing Ctrl-Alt-Backspace). If they don't, then try a different combination of video cards; we couldn't force systems to work that didn't do this step successfully, but we would love to hear about your successes with it! Now type XFree86 -scanpci and record the output. Typical output: (0:8:0) S3 Virge, which is a PCI card, and (1:0:0) NVIDIA Riva Ultra 64, which is an AGP card. Other cards and slots will be identified, but it doesn't matter for this to work.
Configuration of X server: you need to make sure you're calling the right X server, especially if you had an X version less than 4 in step 6. Type ls -l /etc/X11/X. If it is a symbolic link to XFree86, you're using the XFree86 Version 4. If it isn't, back up the link by typing mv /etc/X11/X /etc/X11/X_orig. Make the correct link by typing ln -s /etc/X11/bin/XFree86 /etc/X11/X.
Multihead configuration: at this point, you could just copy the new X configuration file (cp /root/XF86Config.new /etc/X11/XFConfig-4), but your resolution probably wouldn't be very good. A better approach is to edit /etc/X11/XF86Config-4 and incorporate the knowledge gained from going through these steps. We'll cover the fine-tuning in the next section.
Finally, type telinit 5, log in and enjoy. If you're successful, your system will boot up and give you a login screen. The screen on the right is your primary screen; the left screen will come up at the end of the login process.
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
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:
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.
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.
GNOME login/GNOME work environment with one large connected screen. When you maximize a window it will fill its screen.
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).
Red Hat has a hardware browser application at /usr/bin/hwbrowser that gives useful information. This is handy under X to see if both video cards are recognized by the system.
Some cards just don't get along. We successfully tried a number of combinations—a matched pair of ATI Mach64 3D RAGE II PCI cards, an ATI Mach64 AGP and Matrox II PCI card, and an S3 Virge PCI and NVIDIA Riva TNT2 AGP card. We got those combinations working within minutes using the above procedure. We also unsuccessfully tried a Diamond Stealth II S220, which definitely does not play well with others. We could not get this card to work with another at all.
The primary video card is where the BIOS display appears and is what gets Screen0. The video card on the highest number PCI channel is the primary card. Some computer BIOSes give an option to initialize the AGP card first, but this did not work for us because the PCI card still displayed the BIOS, which is too bad, because that level of control over the environment would be useful.
Since you have multiple screens when you use the KDE login manager, the KDE screensaver only works on the primary screen. Set up xscreensaver and call it in your shell initialization files (.bashrc for example) if you want both screens to have a screensaver. It's easy to put one screensaver on one screen and a different one on the other using :0.0 or :0.1 in the configuration.
Put some variable assignments in .bashrc, such as left='-display :0.1' and right='-display :0.0'. Then you can specify which screen to use, e.g., xeyes $left or xclock $right. It helps make things a little simpler to use.
Our current favorite way to work is to utilize the KDE login and the KDE window environment. KDE seems a little cleaner as a work environment and goes across multiple screens (remember that in configuration two with GNOME, you have to start a second window manager). More importantly, the KDE login gives you separate screens so you can open up one screen for people to use (xhost + to disable access control) and still work on the other without security concerns. Also, we tend to devote one screen to monitoring events and displaying things.
The formula presented here is very simple to follow, and a working Linux system can be converted to multiple displays in under ten minutes, if the video hardware supports it. This technique allowed us to utilize otherwise obsolete hardware to simplify our engineering work greatly.
The authors thank Gary Normandin for his insights and hard work testing these methods, Dennis Baker for pointing the way with his Xinerama HOWTO (found at www.linuxdoc.org) and Learning Tree International for letting us use their equipment for some of the testing.
