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

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState