Multiheading Linux Systems
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 EndSectionHere'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" EndSectionThe 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.
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).
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- Users, Permissions and Multitenant Sites
- New Products
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- DevOps: Everything You Need to Know
- High-Availability Storage with HA-LVM
- Tighten Up SSH
- Solving ODEs on Linux
- Non-Linux FOSS: MenuMeters
- March 2015 Issue of Linux Journal: System Administration