...making Linux just a little more fun!
By Alan Ward
Setting up several screens on your Win/Lin box.
This article has been much inspired by a paper entitled "Multihead systems" (I think - I read the Spanish translation called "Sistemas multihead") in Linux Journal, by Brian Gollsneider and Arthur M. Messenger. They're the guys to blame for getting me interested in this!
The "X --help" page ... worth browsing.
As you people know, multiheading is all about hanging many screens on one computer. You can then either use the different screens to display various parts of the same desktop, or different desktops. It has been done with Unix systems since very early on - around about when they invented the X-Windowing system. It can be useful when you tend to get a lot of data on screen -- typical examples are engineering (drawing and 3D models) and system or network monitoring.
Its generalization is a bit more recent under Windows, though several video card makers have pushed the idea with dual-head cards. These are not necessary though; several ordinary video cards can play the trick.
In fact, one can mix many different kinds of ISA, PCI and AGP cards.
In this article, I will see how it works under Windows (98 version - though others should be the same) and Linux + XFree86 version 4. Please note that XFree86 version 3's configuration files are slightly different.
Considerations about hardware
The BIOS will choose one screen to be the primary screen. This is where your boot messages will appear and where you'll get the initial console. The BIOS looks for the primary screen on the following buses in order:
ISA cards: if anybody still uses them, be warned they get preference before all others. Can still be useful for text consoles.
PCI cards. The PCI bus is a mixed thing, in the sense that you get both on-board devices and PCI cards all together. On most motherboards, it is a single bus numbered 0, with devices numbered 0:0 (host controller), 0:1, 0:2 etc. There can be sub-devices such as 0:9:1, 0:9:2, and so forth.
On-board PCI devices get the lower numbers, generally up to 0:7. Afterwards, devices 0:8 to 0:12 should be your PCI slots, numbered from the "bottom" of the motherboard in the direction of the AGP slot.
Almost all motherboards have only one AGP slot, though there is no technical reason why. It is identified as a PCI device on bus 1, as 1:0
For example, if you have one on-board PCI video card, one removable PCI and one AGP, your device ordering might be:
First (main) device: PCI 0:6 (on-board) Second device: PCI 0:10 (removable) Third device: PCI 1:0 (AGP)
Other motherboard manufacturers set up the on-board video devices with higher numbers than the slots. This way, if your on-board video burns out (or you just want to upgrade), you insert a new PCI video card and its lower number gets preference at boot.
You can get detailed information on this under Linux, for example, this system has a single AGP card:
cat /proc/pci PCI devices found: (((snip))) Bus 1, device 0, function 0: VGA compatible controller: Intel Unknown device (rev 33). Vendor id=8086. Device id=7800. Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. No bursts. Prefetchable 32 bit memory at 0xce000000 [0xce000008]. Non-prefetchable 32 bit memory at 0xcfe80000 [0xcfe80000].
Another way (with root privileges) is:
Please note that the order of cards is BIOS stuff -- and so applicable both to Windows and Linux.
Configuration under Windows
This is meant to be pretty easy -- and is, except when you run into driver trouble. So I would advise you to start out by sticking *one* video card into your computer, then making sure you have the necessary drivers. Then go for the next card alone, and so forth. That way you get the pain in small pieces you can hopefully handle, instead of all at once.
When you are confident you have all the required drivers either on CD or on hard disk, and that they actually work with your cards, stick all the video cards in together and hang screens on them. Boot.
You will then get to reconfigure the drivers once more, one after the other. You may also get to reboot the computer -- but you're used to that, right?
At this time, you should get the usual Windows desktop on your first (main) screen, and a text message on all others telling you that Windows has recognized the device correctly. If you don't, go back and reconfigure that video card correctly.
When you take a look at the screen properties, you should see something like this:
You then click on the number 2 screen, activate it, configure, and off you go. So forth for all others. Note that screens need not have the same resolution or color depth:
Hopefully, you are then in business, and can drag windows from one screen to another. Try it!
Configuration with XFree86
XFree86 version 4 has been changed in several ways from its version 3 predecessor. To begin with, the configuration file is now
Please note the -4 ending.
It has now dealt away with the antique separate server binary file for each screen. We now have a more modern modular scheme with a single main server file, plus modules (drivers) for each family of video cards. These can be found in most distributions in:
This is similar to what has happened to the Linux kernel: from a monolithic kernel with all drivers included, modern kernels have progressed to a loadable modular scheme. Luckily for us.
Here's a list of the most-used drivers:
|ati||most early ATI cards|
|r128||ATI Rage-128 and 128-based cards|
|cirrus||Cirrus Logic GD54??|
|cyrix||Cyrix Media GX CPU|
|i740||Intel 740-based cards|
|i810||Intel 810-based cards|
|mga||Matrox 100, 200, 400|
|nv||N-vidia Riva 128, TNT GeForce, etc.|
|s3||S3 non-Virge early PCI chipsets|
|s3virge||S3 Virge later PCI chipsets|
|vga||generic; replaces XFree86-SVGA|
|fbdev||generic; "flat" video memory mode|
This system also means that it will be relatively easy for card manufacturers to produce their own modular drivers to support new cards. Let's hope that they do so.
Configuration is not complicated. The first part of the XF86Config-4 file should be pretty much self-explanatory, and is often rather well set up by your favorite distribution's setup program.
In the Monitor section, each monitor gets its Section tag, such as:
Section "Monitor" Identifier "monitor 1" VendorName "Philips" ModelName "Unknown" HorizSync 30.0-64.0 VertRefresh 50.0-110.0 EndSection
You can put in as many monitors as you wish, and name them. I usually call them "monitor 1" etc., as they are often of the same type and make. But you can handle this whatever way you feel most comfortable with.
BE CAREFUL with the horizontal and vertical frequencies. You can literally blow up your tube if you are not careful. Been there, done that :-( Get the right frequencies from the monitor's guide, or look them up on the manufacturer's site on the Web. If in doubt, go lower. Values that have worked out to be "safe" for me -- i.e. no screens blown up -- have been:
HorizSync 31.5-35.5 VertRefresh 50.0-70.0
Just about any modern multisync monitor can handle these -- however they are so conservative you won't be able to go far beyond 640x480 with 8-bit color (256 colors). Just enough to prove the concept :-)
You then get to set up the driver for each video card. List the directory mentioned above. One Section for each card:
Section "Device" Identifier "device 1" Driver "s3virge" BusID "PCI:0:11:0" EndSection Section "Device" Identifier "device 2" VendorName "Unknown" BoardName "Unknown" Driver "i740" VideoRam 8192 BusID "PCI:1:0:0" EndSection
In this case, I have one S3 card inserted in a PCI slot, and an Intel 740-based AGP card. With a single card, you do not need to look up and specify the bus ID (from /proc/pci). But in our case we need it to distinguish, for example, between several cards of the same type.
In the above example, if I added a second S3 Virge in PCI slot 0:12, I would add a third Device section repeating the "s3virge" driver line, and specifying "PCI:0:12:0". The server is smart enough not to create two instances of the driver in memory, just two references to the same driver.
As with monitors, the Identifier tag set up by the setup program usually contains the card's chipset commercial identifier, though you can change it at will.
You then set up a Screen section linking each Monitor to the appropriate Device. I strip this down to the essentials:
Section "Screen" Identifier "screen 1" Device "device 1" Monitor "monitor 1" DefaultColorDepth 16 Subsection "Display" Depth 16 Modes "1024x768" ViewPort 0 0 EndSubsection EndSection Section "Screen" Identifier "screen 2" Device "device 2" Monitor "monitor 2" DefaultColorDepth 24 Subsection "Display" Depth 24 Modes "800x600" ViewPort 0 0 EndSubsection EndSection
Finally, you set up the whole system:
Section "ServerLayout" Identifier "layout 1" Screen "screen 1" Screen "screen 2" RightOf "screen 1" Option "Xinerama" "on" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection
Here, I have screen 2 at the right of screen 1. I could also have specified it to be at the left, above of below any existing screen.
The Xinerama option is also important. This is an extension of the X server that links screen 1 with screen 2, to form a single desktop I can drag windows and icons across.
This works in the same way as Windows, but needs both (or all) screens to have the same color depth: generally 8, 16 or 24 bits. This means the above example shouldn't work! (Read it again to make sure you understand why before reading on.)
But you may prefer two screens with separate desktops. For example, you could have one screen for your own use, and make the other available over your local network. Or one screen with KDE and the other without any window manager. Your choice. This can be done simply by turning off Xinerama:
Option "Xinerama" "off"
Finally, you may prefer to keep a screen for the text console: include "screen 2", "screen 3", etc in your ServerLayout section, omitting "screen 1" (generally the console if where you boot from and where you get system error messages).
Trying out XFree
As with Windows, it is best to start out by testing each video card individually. Start at the text console (runlevel 3). Keep one screen in your ServerLayout, commenting out the others with a # at the beginning of the line. You can then start up the X server (no need for a desktop yet):
You should get a black-and-white crisscross pattern, with an X-shaped mouse cursor in the middle. Good. You can shut down X and get back to the text console with
Ctrl + Alt + Backspace
Now do the same for the other cards. When you have everything set up, just uncomment all screen entries in ServerLayout, and test X once more. You should now get the crisscross pattern on all screens, and if you activated Xinerama, the mouse should move between screens.
<smirk>And you didn't need to reboot, did you?</smirk>
You can now either go directly into the graphical desktop with startx, or switch to a graphical login with runlevel 5:
Comparison between Windows and Linux
As usual, there are differences between either way of doing things, and thus between the end results. To be objective:
- Windows lets you use devices with different levels of color and resolutions together as part of the same desktop. However, it cannot handle more than one desktop, nor can it mix text consoles with graphics.
- Windows can be a pain to configure, with much rebooting.
- conversely, Linux can mix text screen with graphics -- this is great for keyboard-trained systems administrators --, can use more than one desktop, or can use all screens (or a combination of screens) for a single desktop. If you want KDE and Gnome at the same time, you get it. If you just want one single big WindowMaker, you get that. If you want to set up a 2x2 or 3x3 video wall, all you need are enough cards, and enough slots to set them in.
- If you want to mix screens with Xinerama under Linux, you need to use the same color depth on all of them.
- Linux with XFree86 version 4 is much easier to configure -- though maybe that's my bias showing through.
Seriously though, the last time I installed Mandrake 8.2, it detected all video cards and went multihead all on its own. Good show.
One last warning the reader may do well to heed: do this on a computer with backups up to date, not on a production machine. Video cards are tricky little things that can bite.
PS. Should anybody want to translate this article: I wrote it in the spirit of the GPL software licence. i.e. you are free (and indeed encouraged) to copy, post and translate it -- but please, PLEASE, send me notice by email! I like to keep track of translations -- it's good for the curriculum :-)