From: Frederick (Rick) A Niles <niles@axp745.gsfc.nasa.gov> To: linux-kernel@vger.rutgers.edu Subject: Beta Draft: Multi-Head Mini HOWTO Date: Thu, 06 May 99 21:51:16 -0400 Please review and send me nasty mail about how wrong I am... Thanks, Rick Niles. ----------- The Multi-Head Mini-HOWTO Rick Niles, Frederick.A.Niles@gsfc.nasa.gov v0.02, April 17, 1999 This document attempts to answer basic questions on how to connect your Linux box to multiple monitors. ______________________________________________________________________ Table of Contents 1. Introduction 1.1 New Versions of this Document 1.2 Feedback 1.3 Contributors 1.4 Standard Disclaimer 1.5 Copyright Information 2. What hardware is supported? 2.1 Commercial support 3. Getting all the stuff. 4. Getting Started 4.1 Move a console over... 4.2 Use "fbset" to adjust the setting on this second monitor 4.3 Set up X for Frame Buffer support. 4.4 Try starting the X server on the second monitor. 5. Summary 6. Other Notes and Problems 7. Related documents Appendix A. Octave cvtmode.m script Appendix B. Borne Shell script "cvtfile" ______________________________________________________________________ 1. Introduction The main goal of this document is to get you started with running a dual head configuration of Linux. While this process is pretty straight forward there are numerous things that one can do wrong along the way. The example I concentrate on is getting an X-server running on a second monitor. I find this nice as you can usually find old large 19" to 21" fixed frequency monitors around that people are giving away because they can't use them. This way you can boot off a small multisync and then use X on a nice big monitor. Please understand dual head support is currently developing so this information changes rapidly. Anything in this document could be out of date or just plain incorrect by the time you are reading this. 1.1 New Versions of this Document New versions of this document will be periodically posted to comp.os.linux.answers. They will also be added to the various anonymous FTP sites who archive such information. In addition, you should generally be able to find this document on the Linux Documentation Project page via: http://metalab.unc.edu/pub/Linux/docs/LDP/ 1.2. Feedback Feedback is most certainly welcome for this document. Without your submissions and input, this document wouldn't exist. So, please post your additions, comments and criticisms to: Frederick.A.Niles@gsfc.nasa.gov. 1.3. Contributors The following people have contributed to this mini-HOWTO. * Petr Vandrovec <vandrove@vc.cvut.cz> 1.4. Standard Disclaimer No liability for the contents of this document can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies that could be damaging to your system. Proceed with caution, and although this is highly unlikely, I don't take any responsibility for that. 1.5. Copyright Information This document is copyrighted (c)1999 Frederick Niles and distributed under the following terms: * Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. * All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. * If you have questions, please contact, the Linux HOWTO coordinator, at linux-howto@sunsite.unc.edu ______________________________________________________________________ 2. What hardware is supported? Most video cards assume they will be the only one in the system and are permanently set with the addressing of the primary display adapter. There are a few exceptions. * Matrox cards: This includes Matrox Millennium, Matrox Millennium II, Matrox Mystique, Matrox Mystique 220, Matrox Productiva G100, Matrox Mystique G200, Matrox Millennium G200 and Matrox Marvel G200 video cards * MDA: This includes monochrome Hercules graphics adapter among others. This for text only second head support. 2.1 Commercial support This mini-HOWTO in primarily concerned with free software. However, there are commercial X servers with multi-head support. These include Metro Link's (www.metrolink.com) Metro-X and Xi Graphics' (www.xig.com) Accelerated-X. ______________________________________________________________________ 3. Getting all the stuff. You'll need the following patches and programs: * "fbset" program try: http://www.cs.kuleuven.ac.be/~geert/bin/ * "fbaddon" Matrox dual head patches for Linux kernel try: ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/ * "con2fb" program try: ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/ * The X11 frame buffer server XF86_FBDev. This is a standard part of XFree86 3.3.1. ______________________________________________________________________ 4. Getting Started The first thing you'll need to do is to patch a copy of the Linux source with the "fbaddon" patch. Then you need to configure the kernel and turn on frame buffer support. If you have Matrox cards turn on Matrox unified accelerated driver support as well as the particular type of card you have. Don't turn on VESA frame buffer support. It can cause a conflict. Do turn on multi-head support (obviously). Build the kernel and reboot. Now you need to install the "fbset" program and carefully read all the documentation on how to adjust the settings. Using a "/etc/fb.modes" file is highly recommended once you've decided on your settings. The fbset program includes a Perl script to convert your XF86Config file to fb.modes settings. I've included my octave/Borne shell script to convert your XF86Config file in Appendix A & B. You need to get comfortable with using the frame buffer device on one monitor, understanding any issues that can arise from your set up that have nothing to do with multi-head support. This can save a lot of head scratching later. I'm going to concentrate my explanation on getting X running on the second monitor as doing most other configurations will just be a obvious subset of the procedure. 4.1 Move a console over... Compile the "con2fb" program. If you run it without any arguments you'll get the following usage message: "usage: con2fb fbdev console". Thus, an example command would be "con2fb /dev/fb1 /dev/tty6" to move virtual console number six over to the second monitor. Use Ctrl-Alt-F6 to move over to that console and see that it does indeed show up on the second monitor. 4.2 Use "fbset" to adjust the setting on this second monitor Only set the "fbset" settings on the monitor you run the "fbset" command on. Therefore, you must be careful to use the "-fb" flag on the second monitor. In particular, if you do nothing else you'll probably want to at least set the virtual vertical resolution to your actually vertical resolution. e.g. "fbset -fb /dev/fb1 -vyres 600" This will seriously slow down text mode, but X will be obnoxious without it. 4.3 Set up X for Frame Buffer support. The framebuffer.txt file explains this better than I can, but here's the two important points. Make sure you set the link for "X" to point to "XF86_FBDev". Next you need to add a monitor section to your XF86Config file for the frame buffer device. Here's an example: # The Frame Buffer server Section "Screen" Driver "fbdev" Device "Millennium" Monitor "NEC MultiSync 5FGp" Subsection "Display" Depth 8 Modes "default" ViewPort 0 0 EndSubsection Subsection "Display" Depth 16 Modes "default" ViewPort 0 0 EndSubsection Subsection "Display" Depth 24 Modes "default" ViewPort 0 0 EndSubsection Subsection "Display" Depth 32 Modes "default" ViewPort 0 0 EndSubsection EndSection Use the "default" modes as I don't think any other one will work with the Matrox frame buffer. 4.4 Try starting the X server on the second monitor. Set the variable FRAMEBUFFER to the second frame buffer. "export FRAMEBUFFER=/dev/fb1" or "setenv FRAMEBUFFER /dev/fb1" You need to start the X server so that it both matches the selected color depth and it appears on the same monitor you start the X server from. e.g. "startx -- -bpp 16 vt06" This example will start the X server on virtual console six with 16 bit color. ______________________________________________________________________ 5. Summary The steps involved in getting an X server running on a second monitor can be summarized as follows: * Get the kernel patch, fbset, and con2fb. * Patch the kernel, configure, rebuild, and reboot. * Add XF86_FBDev section to XF86Config file and set X link. Then each time you reboot: * Move a console over. e.g. "con2fb /dev/fb1 /dev/tty6" * Adjust the settings e.g. "fbset -fb /dev/fb1 1280x1024" * Set the FRAMEBUFFER. e.g. "export FRAMEBUFFER=/dev/fb1" * Start the X server. e.g. "startx -- -bpp 16 vt06" You can automate this each time you reboot via a shell alias. It must be an alias and not a shell script since it needs to detect the current console number. This is my C-shell alias to start up X on a second fixed frequency monitor: alias startxfb = " setenv FRAMEBUFFER /dev/fb\!*; # Set the env var to the cmd arg. con2fb $FRAMEBUFFER /dev/$tty; # Move the fb to the current tty. fbset -fb $FRAMEBUFFER 1280x1024@62; # Favorite from /etc/fb.modes startx -- -bpp 16 vt0`echo $tty | cut -dy f 2`' # X on this tty. " In my .cshrc file these are all on the same line together without the comments, but it's easier to read here with line breaks and comments inserted. I just give the number of the frame buffer as an argument and it starts right up. I'm not sure how to do this same alias in bash. I don't know how to determine the current tty or get the arguments to an alias in bash. If someone lets me know I'll insert it here. ______________________________________________________________________ 6. Other Notes and Problems * Both "fbset" and "startx" MUST be run from the same frame buffer as the one being affected. This places serious limits on how much of these commands can be automated via scripts. * XFree86 4.0 will have multi-head support, but 3.3.1 does not. Since you can only have one X server running on one machine at a time, only one monitor can be in X at a time. * The monitor that's not selected doesn't always preseve it's state when not active. (But it usually does.) * Linus Torvalds doesn't agree with the current multi-head console support changes so it may never be in the mainstream kernel tree. (This was heard third hand and may be wildly untrue.) * If you "break the rules" and start the X server (run "startx") from a different monitor, the machine can eventually crash badly with the keyboard and mouse input all mixed together. * The documentation framebuffer.txt in the kernel source explains that you can use the Modeline settings in your XF86Config file directly when running X. Using the Matrox frame buffer seems to force the X server to drop all of those. So you can only have the one ("default") setting at at time (the same one you had in text mode). * The XF86_FBDev is unaccelerated. However, there are patches for accelerated Matrox support at http://www.in-berlin.de/User/kraxel/xfree86/ ______________________________________________________________________ 7. Related documents * The Frame Buffer HOWTO * All the documents in the frame buffer section of the Linux kernel source: linux/Documentation/fb/ In particular: framebuffer.txt and matroxfb.txt * The man pages included with "fbset". * The XFree86 release notes on the XF86_FBDev X server ______________________________________________________________________ Appendix A. Octave cvtmode.m script (note the bpp setting) #!/usr/bin/octave -q bpp = 16; DCF = sscanf(argv(1,:), "%f"); HR = sscanf(argv(2,:), "%f"); SH1 = sscanf(argv(3,:), "%f"); SH2 = sscanf(argv(4,:), "%f"); HFL = sscanf(argv(5,:), "%f"); VR = sscanf(argv(6,:), "%f"); SV1 = sscanf(argv(7,:), "%f"); SV2 = sscanf(argv(8,:), "%f"); VFL = sscanf(argv(9,:), "%f"); pixclock = 1000000 / DCF; left_margin = HFL - SH2; right_margin = SH1 - HR; hsync_len = SH2 - SH1; # 3) vertical timings: upper_margin = VFL - SV2; lower_margin = SV1 - VR; vsync_len = SV2 - SV1; RR = DCF / (HFL * VFL) *1e6; HSF = DCF / HFL * 1e3; printf("mode \"%dx%d\"\n",HR,VR); printf(" # D: %3.2f MHz, H: %3.2f kHz, V: %2.2f Hz\n", DCF, HSF, RR); printf(" geometry %d %d %d %d %d\n", HR, VR, HR, VR, bpp); printf(" timings %d %d %d %d %d %d %d\n", ... pixclock, left_margin, right_margin, ... upper_margin, lower_margin, ... hsync_len, vsync_len); printf("endmode\n"); ______________________________________________________________________ Appendix B. Borne Shell script "cvtfile" (This calls the octave script "cvtmode") #!/bin/sh # Shell script to convert XF86Config file to fb.modes file. # Uses octave script cvtmode.m if [ -z $1 ]; then FILE=/etc/X11/XF86Config else FILE=$1 fi i=1 LEN=`grep Modeline $FILE | wc -l` while expr $i \< $LEN > /dev/null ; do CURLINE=`grep Modeline $FILE | cut -d'"' -f 3-20 | head -$i | tail -1 ` ./cvtmode.m $CURLINE echo " " i=`expr $i + 1` done ______________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/