Multiheading Linux Systems
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.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development