--- xtheory.mm	2002/03/23 05:04:44	4.1
+++ xtheory.mm	2003/05/18 02:19:19
@@ -1,9 +1,8 @@
 \" This file is in -*- nroff-fill -*- mode
-.\" STATUS: draft 4th edition
-.\" $Id: xtheory.mm,v 4.1 2002/03/23 05:04:44 grog Exp $
+.\" STATUS: 4th edition
+.\" $Id: xtheory.mm,v 4.14 2003/05/18 02:19:19 grog Exp $
 .\"
 ..if article
-.\".fam G
 .ce 2
 \s17Setting up the X Window System\s0
 .sp
@@ -11,7 +10,7 @@
 .sp .4i
 .2C
 .\" .nr Fs .5 \" Footnote spacing
-Most people know Microsoft's ``Windows'' series of ``Operating Systems''.  From
+Most people know Microsoft's ``Windows'' series of ``Operating Systems.''  From
 a UNIX point of view, they're not really operating systems at all: their main
 function is display management.  UNIX systems use a separate software package
 for display management, usually the X window system, often called simply
@@ -34,7 +33,7 @@
 .br
 X11
 .P
-\fI``X Window System''\fP\| is a trademark of X Consortium, Inc.
+\fI``X Window System''\fP\/ is a trademark of X Consortium, Inc.
 .br
 .in
 .ll
@@ -53,7 +52,7 @@
 .P
 It's a sign of the times that XInside has also had to change its name.  They
 published this press announcement at
-\fIhttp://www.xig.com/ci/pr/970219.xigraphics.html\fP\|:
+\fIhttp://www.xig.com/ci/pr/970219.xigraphics.html\fP\/:
 .P
 .in +.1i
 .ll -.2i
@@ -93,7 +92,7 @@
 .LI
 How to install XFree86.
 .LI
-How to set up a \fIwindow manager\fP.  A window manager is a program which
+How to set up a \fIwindow manager\fP.  A window manager is a program that
 controls the placement and the appearence of windows on the screen.  Several
 different window managers are available for X, and they offer a bewildering
 number of options.
@@ -102,14 +101,32 @@
 subjects interest you?  Send mail to Free Systems Journal, or personally to me
 (\f(CWgrog@lemis.com\fP) and let us know.
 ..else
-.Chapter \*[nchxtheory] "XFree86 configuration in depth"
-In most cases, the information in \*[chdesktop], should be enough to get X up
-and running.  If it doesn't work for some reason, or if you're a masochist, or
-if you just want to understand the procedure better, this chapter should be able
-to help.
-.P
-In the next section, we'll look at the technical background, and on page
-\*[doxconfig] we'll look at setting up the \fIXF86Config\fP\| file.
+.\" ******* Start of book chapter
+.Chapter \*[nchxtheory] "XFree86 in depth"
+The information in Chapter
+.Sref \*[nchpostinstall] \&
+should be enough to get X up and running.  There's a lot more to X than that,
+however, enough to fill many books.  In this chapter we'll look at some of the
+more interesting topics:
+.Ls B
+.LI
+The next section describes the technical background of running X displays.
+.LI
+On page
+.Sref \*[doxconfig] \&
+we'll look at setting up the
+.File XF86Config
+file.
+.LI
+On page
+.Sref \*[multihead] \&
+we'll look at using more than one monitor with X.
+.LI
+On page
+.Sref \*[network-X] \&
+we'll look at using X in a network.
+.Le
+.SPUP
 ..if article
 .H2 "The problem with boards and monitors"
 PCs have arguably the highest performance/price ratio of any computer family.
@@ -136,11 +153,10 @@
 .P
 ..else
 .H2 "X configuration: the theory"
-.Pn Xtheory
-..endif
-Setting up your \fIXF86Config\fP\| file normally takes a few minutes, but
-sometimes you can run into problems which make grown men cry.  In the rest of
-this 
+Setting up your
+.File XF86Config
+file normally takes a few minutes, but sometimes you can run into problems that
+make grown men cry.  In the rest of this
 ..if article
 article,
 ..else
@@ -158,14 +174,14 @@
 How to fry your monitor.
 .Le
 I mean the last point seriously: conventional wisdom says that you can't damage
-hardware with a programming mistake, but in this case, you can, and people do it
-from time to time.  When you've read the section on how monitors work, you'll
-understand, but \fIplease\fP\| don't start tuning until you understand the dangers
-involved.
+hardware with a programming mistake, but in this case it is possible.  Read the
+section on how monitors work, and don't start tuning until you understand the
+dangers involved.
+..endif
 .H3 "How TVs and monitors work"
 You don't have to be a computer expert to see the similarity between monitors
-and TVs: current monitor technology is derived from TV technology, and most
-older display boards have modes which can use TVs instead of monitors.  Those of
+and TVs: current monitor technology is derived from TV technology, and many
+older display boards have modes that can use TVs instead of monitors.  Those of
 us who were on the microcomputer scene 20 to 25 years ago will remember the joy
 of getting a computer display on a portable TV, a ``glass tty'' connected by a
 serial line running at 300 or 1200 bps.
@@ -173,38 +189,27 @@
 There are at least two ways to create pictures on a cathode ray tube: one is
 derived from oscilloscopes, where each individual character is scanned by the
 electron beam, rather like writing in the sand with your finger.  Some early
-terminals used this technology, but it has been obsolete for at least 25 years.
+terminals used this technology, but it has been obsolete for several decades.
 .P
-TVs and monitors display the picture by scanning lines across the screen.  Like
-in a book, the first line starts at the top left of the screen and goes to the
-top right.  Each successive line starts slightly below the previous line.  This
-continues until the screen is full.  Like in a book, the lines don't have to be
-full: the picture is formed by altering the intensity of the electron beam as it
-scans the lines.
+TVs and monitors display the picture by scanning equally spaced lines across the
+entire screen.  Like in a book, the first line starts at the top left of the
+screen and goes to the top right.  Each successive line starts slightly below
+the previous line.  This continues until the screen is full.  The picture is
+formed by altering the intensity of the electron beam as it scans the lines.
 .P
-.X "deflection units"
+.X "deflection unit"
 .X "deflection, horizontal"
 .X "deflection, vertical"
 .X "deflection, line"
 .X "deflection, frame"
-To perform this scan, the TV has two \fIdeflection units\fP\|: one scans from left
+To perform this scan, the TV has two \fIdeflection units\fP\/: one scans from left
 to right, and the other scans, much more slowly, from top to bottom.  Not
-surprisingly, these units are called the \fIhorizontal\fP\| and \fIvertical\fP\|
-deflection units.  You may also encounter the terms \fIline\fP\| and \fIframe\fP\|
+surprisingly, these units are called the \fIhorizontal\fP\/ and \fIvertical\fP\/
+deflection units.  You may also encounter the terms \fIline\fP\/ and \fIframe\fP\/
 deflection.
-.P
-.X "flyback, horizontal"
-.X "flyback, vertical"
-The tube can only move the electron beam at a finite speed.  When the electron
-beam reaches the right hand side of the screen, it needs to be deflected back
-again.  This part of the scan is called the \fIhorizontal flyback\fP, and it is
-not used for displaying picture data.  The actual time that the hardware
-requires for the flyback depends on the monitor, but it is in the order of 5% to
-10% of the total line scan time.  Similarly, when the vertical deflection
-reaches the bottom of the screen, it performs a \fIvertical flyback\fP, which is
-also not used for display purposes.
+.P\" *** This is where the figure starts
 .ie n \{\
-The printed version of this book includes diagrams which are impossible to
+The printed version of this book includes diagrams that are impossible to
 reproduce in ASCII.  Sorry about that\(emabout the only thing I can suggest is
 to get hold of the book.
 \}
@@ -216,16 +221,12 @@
 .Sref \*[scan-pattern] \&
 ..endif
 shows the resultant pattern.
-..if article
-..else
-.Df
-..endif
 .PS
 [
 ..if article
 TV: box wid 1.6i height 1.2i
 ..else
-move right 1.3i
+move right .5i
 TV: box wid 3.2i height 2.4i
 ..endif
 A: line from TV.nw+ (.1i,-.1i) to TV.ne + (-.1i,-.1i)
@@ -254,31 +255,43 @@
 ..else
 .ce
 .Figure-heading "Scanning pattern on the monitor"
-.Tn scan-pattern
-.DE
+.Fn scan-pattern
 ..endif
 .\}
+.\" *** The figure ends here
+.X "flyback, horizontal"
+.X "flyback, vertical"
+.ne 2v
+The tube can only move the electron beam at a finite speed.  When the electron
+beam reaches the right hand side of the screen, it needs to be deflected back
+again.  This part of the scan is called the \fIhorizontal flyback\fP, and it is
+not used for displaying picture data.  The actual time that the hardware
+requires for the flyback depends on the monitor, but it is in the order of 5% to
+10% of the total line scan time.  Similarly, when the vertical deflection
+reaches the bottom of the screen, it performs a \fIvertical flyback\fP, which is
+also not used for display purposes.
 .P
 It's not enough to just deflect, of course: somehow you need to ensure that the
 scanning is synchronized with the incoming signal, so that the scan is at the
 top of the screen when the picture information for the top of the screen
-arrives.  You've seen what happens when this doesn't happen: the picture runs up
-and down the screen (incorrect vertical synchronization) or tears away from the
-left of the screen (incorrect horizontal synchronization).  Synchronization is
-achieved by including synchronization pulses in the horizontal and vertical
-flyback periods.  They have a voltage level outside the normal picture data
-range in order to ensure that they are recognized as synchronization pulses.
+arrives.  You've seen what happens when synchronization doesn't work: the
+picture runs up and down the screen (incorrect vertical synchronization) or
+tears away from the left of the screen (incorrect horizontal synchronization).
+Synchronization is achieved by including synchronization pulses in the
+horizontal and vertical flyback periods.  They have a voltage level outside the
+normal picture data range to ensure that they are recognized as synchronization
+pulses.
 .P
-.X "video blanking"
+.X "video, blanking"
 .X "porch, front"
 .X "porch, back"
-As if that wasn't enough, the video amplifier, the part of the TV which alters
+As if that wasn't enough, the video amplifier, the part of the TV that alters
 the intensity of the spot as it travels across the screen, needs time to ensure
 that the flyback is invisible, so there are brief pauses between the end of the
 line and the start of the sync pulse, and again between the end of the sync
 pulse and the beginning of the data.  This process is called \fIblanking\fP, and
-the delays are called the \fIfront porch\fP\| (before the sync pulse) and the
-\fIback porch\fP\| (after the sync pulse).
+the delays are called the \fIfront porch\fP\/ (before the sync pulse) and the
+\fIback porch\fP\/ (after the sync pulse).
 .ie n \{\
 In the printed version of this book there's another diagram here.
 \}
@@ -342,7 +355,7 @@
 p125=1.25i
 p170=1.7i
 p07=.07i
-move right 1i
+move right .5i
 ..endif
 line dotted p02 right p1;					# end of previous line
 A: line dotted p02 up p100 then right p15;			# start of sync pulse
@@ -431,7 +444,7 @@
 ..else
 .ce
 .Figure-heading "Scan line and register values"
-.Tn waveform-figure
+.Fn waveform-figure
 ..endif
 .\}
 .P
@@ -450,19 +463,19 @@
 display mechanism was developed for TVs in the 1930s, at a time when terms like
 high-tech (or even electronics) hadn't even been invented, and even today we're
 stuck with the low data rates that they decided upon in those days.  Depending
-on the country, TVs display only 25 or 30 frames (pages of display) per second.
-This caused an unpleasant flicker in the display.  This flicker was avoided with
-a trick called \fIinterlacing\fP\|: instead of displaying the frame in one
-vertical scan, the odd and even lines are displayed in two alternating half
-frames, which increases the apparent frame frequency to 50 or 60 Hz.
+on the country, conventional TVs display only 25 or 30 frames (pages of display)
+per second.  This would cause an unpleasant flicker in the display.  This
+flicker is minimized with a trick called \fIinterlacing\fP\/: instead of
+displaying the frame in one vertical scan, the odd and even lines are displayed
+in two alternating half frames, which doubles the apparent vertical frequency.
 .H3 "How monitors differ from TVs"
 So how do we apply this to computer displays?  Let's look at the US standard
 NTSC system\(emthe international PAL and SECAM systems are almost identical
-except for the number of lines and a minor difference in the vertical frequency.
-NTSC specifies 525 lines, but that includes the vertical flyback time, and in
-fact only about 480 lines are visible.  The aspect ratio of a normal TV is 4:3,
-in other words the screen is one-third wider than it is high, so if we want
-square pixels,\*F
+except for the number of lines and a minor difference in the frequencies.  NTSC
+specifies 525 lines, but that includes the vertical flyback time, and in fact
+only about 480 lines are visible.  The aspect ratio of a normal TV is 4:3, in
+other words the screen is one-third wider than it is high, so if we want square
+pixels,\*F
 .FS
 A square pixel is one with the same height and width.  They don't have to be
 that way, but it makes graphics software much simpler.
@@ -470,10 +483,10 @@
 we need to have one-third more pixels per line.  This means that we can display
 640 pixels per line on 480 lines.\*F
 .FS
-Does this look familiar?  Now you know why.
+Does this look familiar?
 .FE
-This resolution is normally abbreviated to ``640x480''.  PAL and SECAM have
-lower vertical frequencies, which allows a nominal 625 lines, of which about 580
+This resolution is normally abbreviated to ``640x480.''  PAL and SECAM have
+lower vertical frequencies, which allows a nominal 625 lines, of which about 600
 are displayed.  Either way, these values have two huge disadvantages: first, the
 resolution is barely acceptable for modern graphics displays, and secondly they
 are interlaced displays.  Older PC display hardware, such as the CGA and some
@@ -492,7 +505,7 @@
 hand, even 60 Hz refresh rate is barely adequate: read any marketing literature
 and you'll discover that 72 Hz is the point at which flicker suddenly
 disappears.  To get high-resolution, high refresh rate displays, you need some
-very high internal frequencies\(emwe'll see how high further down.
+very high internal frequencies\(emwe'll look at that further down.
 .H3 "How to fry your monitor"
 .Pn fry-monitor
 .X "line transformer"
@@ -501,61 +514,60 @@
 only a single vertical frequency.  This simplifies the hardware design
 considerably: the horizontal deflection uses a tuned circuit to create both the
 deflection frequency and the high voltage required to run the tube.  This
-circuit is comprised of a transformer (the \fIline transformer\fP\|) and a
+circuit is comprised of a transformer (the \fIline transformer\fP\/) and a
 condenser.  Run a line transformer even fractionally off its intended frequency
-and it will run much less efficiently and use more current, which gets converted
-to heat.  If you run a conventional monitor off spec for any length of time, it
+and it runs much less efficiently and use more current, which gets converted to
+heat.  If you run a conventional monitor off spec for any length of time, it
 will burn out the line transformer.
 .P
-You don't have to roll your own X configuration to burn out the monitor: ten
+You don't have to roll your own X configuration to burn out the monitor: 20
 years ago, the standard display boards were CGAs and HDAs,\*F
 .FS
 Color Graphics Adapter and Hercules Display Adapter.
 .FE
-and they had different line frequencies and thus required different monitors.
-Unfortunately, they both used the same data connector.  If you connected an HDA
-(18.43 kHz line frequency) to a CGA monitor (15.75 kHz, the NTSC line
-frequency), you could expect smoke signals within a few minutes.
-.P
-Modern PC monitors no longer use line transformers, and there are few of them
-which can't handle at least a range of line frequencies, this doesn't mean that
-an out of spec signal can't damage them\(emyou'll just burn out something else,
-frequently the power supply.  Most modern monitors recognize out-of-spec signals
-and refuse to try to display them; instead, you get an error display.
-Unfortunately, many monitors, especially older or cheaper models, don't protect
-themselves against out of spec signals.  In addition, just because the monitor
-displays correctly doesn't mean that it is running in spec.  The moral of the
-story:
+and they had different horizontal frequencies and thus required different
+monitors.  Unfortunately, they both used the same data connector.  If you
+connected an HDA (18.43 kHz horizontal frequency) to a CGA monitor (15.75 kHz,
+the NTSC line frequency), you would soon see smoke signals.
+.P
+All modern PC monitors handle at least a range of horizontal frequencies.  This
+doesn't mean that an out of spec signal can't damage them\(emyou might just burn
+out something else, frequently the power supply.  Most better monitors recognize
+out-of-spec signals and refuse to try to display them; instead, you get an error
+display.  Unfortunately, there are plenty of other monitors, especially older or
+cheaper models, which don't protect themselves against out of spec signals.  In
+addition, just because the monitor displays correctly doesn't mean that it is
+running in spec.  The moral of the story:
 .Highlight
-Never run your monitor out of spec.  If your display is screwed up, there's a
+Never run your monitor out of spec.  If your display is messed up, there's a
 good chance that the frequencies are out, so turn off the monitor.
 .End-highlight
 .P
 Monitors aren't the only thing that you can burn out, of course.  If you try
 hard, you can also burn out chips on some display boards by running them at
-frequencies which are out of spec.  In practice, though, this doesn't happen
+frequencies that are out of spec.  In practice, though, this doesn't happen
 nearly as often.
 .P
 .X "video, composite"
 .X "composite video"
 Another difference between TVs and monitors is the kind of signal they take.  A
 real TV includes a receiver, of course, so you have an antenna connection, but
-modern TVs also have connections for inputs from VCRs, which are usually an
-audio signal and a video signal.  The video signal consists of five important
-parts: the \fIred\fP\| signal, the \fIgreen\fP\| signal, the \fIblue\fP\| signal, and
-the horizontal and vertical sync pulses.  This kind of signal is called
-\fIcomposite video\fP.  By contrast, most modern monitors separate these signals
-onto separate signal lines, and older boards, such as the EGA, even used several
+modern TVs also have connections for inputs from VCRs, which are usually two
+audio signals and a video signal.  The video signal contains five important
+components: the \fIred\fP, \fIgreen\fP and \fIblue\fP\/ signals, and the
+horizontal and vertical sync pulses.  This kind of signal is called \fIcomposite
+video\fP.  By contrast, most modern monitors separate these signals onto
+separate signal lines, and older boards, such as the EGA, even used several
 lines per colour.  Unfortunately, there is no complete agreement about how these
-signals should work: the polarity of the sync pulses varies from one board to
-the next, and some boards cheat and supply the sync pulses on the green signal
-line.  This is mainly of historical interest, but occasionally you'll come
-across a real bargain 20" monitor which only has 3 signal connections, and you
-may not be able to get it to work\(emthis could be one of the reasons.
+signals should work: the polarity of the sync pulses can vary, and some boards
+cheat and supply the sync pulses on the green signal line.  This is mainly of
+historical interest, but occasionally you'll come across a real bargain 20"
+monitor that only has three signal connections, and you may not be able to get
+it to work\(emthis could be one of the reasons.
 .H3 "The CRT controller"
 .Pn setting-video-regs
 The display controller, usually called a CRT (Cathode Ray Tube) controller, is
-the part of the display board which creates the signals we've just been talking
+the part of the display board that creates the signals we've just been talking
 about.  Early display controllers were designed to produce signals that were
 compatible with TVs: they had to produce a signal with sync pulses, front and
 back porches, and picture data in between.  Modern display controllers can do a
@@ -582,47 +594,36 @@
 .\}
 .Ls B
 .LI
-.X "register, Horizontal Display End"
-The \fIHorizontal Display End\fP\| register (HDE) specifies how many dots we want
+.X "registers, video card"
+The \fIHorizontal Display End\fP\/ register (HDE) specifies how many dots we want
 on each line.  After the CRTC has counted this many pixels, it stops outputting
 picture data to the display.
 .LI
-.X "register, Start Horizontal Retrace"
-The \fIStart Horizontal Retrace\fP\|
+The \fIStart Horizontal Retrace\fP\/
 register (SHR) specifies how many dot clock
 pulses occur before the sync pulse starts.  The difference between the contents
 of this register and the contents of the HDE register defines the length of the
 front porch.
 .LI
-.X "register, End Horizontal Retrace"
-The \fIEnd Horizontal Retrace\fP\|
+The \fIEnd Horizontal Retrace\fP\/
 register (EHR) defines the end of the sync
 pulse.  The width of the sync pulse is the difference between the contents of
 this register and the SHR register.
 .LI
-.X "register, Horizontal Total"
-The \fIHorizontal Total\fP\|
+The \fIHorizontal Total\fP\/
 register (HT) defines the total number of dot clocks
 per line.  The width of the back porch is the difference between the contents of
 this register and the EHR register.
 .Le
-.X "register, Start Horizontal Blanking"
-.X "register, End Horizontal Blanking"
-In addition, the \fIStart Horizontal Blanking\fP\| and \fIEnd Horizontal
-Blanking\fP\| registers (SHB and EHB) define when the video signals are turned off
+In addition, the \fIStart Horizontal Blanking\fP\/ and \fIEnd Horizontal
+Blanking\fP\/ registers (SHB and EHB) define when the video signals are turned off
 and on.  The server sets these registers automatically, so we don't need to look
 at them in more detail.
 .P
-.X "register, Vertical Display End"
-.X "register, Start Vertical Retrace"
-.X "register, End Vertical Retrace"
-.X "register, Vertical Total"
-.X "register, Start Vertical Blanking"
-.X "register, End Vertical Blanking"
 The control of the vertical deflection is similar.  In this case, the registers
-are \fIVertical Display End\fP\| (VDE), \fIStart Vertical Retrace\fP\| (SVR), \fIEnd
-Vertical Retrace\fP\| (EVR), \fIVertical Total\fP\| (VT), \fIStart Vertical
-Blanking\fP\| (SVB), and \fIEnd Vertical Blanking\fP\| (EVB).  The values in these
+are \fIVertical Display End\fP\/ (VDE), \fIStart Vertical Retrace\fP\/ (SVR), \fIEnd
+Vertical Retrace\fP\/ (EVR), \fIVertical Total\fP\/ (VT), \fIStart Vertical
+Blanking\fP\/ (SVB), and \fIEnd Vertical Blanking\fP\/ (EVB).  The values in these
 registers are counted in lines.
 .P
 VGA hardware evolved out of older 8 bit character-based display hardware, which
@@ -640,6 +641,7 @@
 the first 8 bits are in the VT register, the 9th bit is in bit 0 of the overflow
 register, and the 10th bit is in bit 5 of the overflow register.
 .H3 "The XF86Config mode line"
+.Pn ModeLine
 One of the steps in setting up XFree86 is to define these register values.
 Fortunately, you don't have to worry about which bits to set in the overflow
 register: the mode lines count in dots, and it's up to the server to convert the
@@ -652,12 +654,12 @@
 end of the line.  The values are:
 .Ls B
 .LI
-.X "XF86Config"
 A label for the resolution line.  This must be enclosed in quotation marks, and
-is used to refer to the line from other parts of the \fIXF86Config\fP\| file.
-Traditionally, the label represents the resolution of the display mode, but it
-doesn't have to.  In this example, the resolution really is 640x480, but the
-\f(CWa\fP at the end of the label is a clue that it's an alternative value.
+is used to refer to the line from other parts of the
+.File XF86Config
+file.  Traditionally, the label represents the resolution of the display mode,
+but it doesn't have to.  In this example, the resolution really is 640x480, but
+the \f(CWa\fP at the end of the label is a clue that it's an alternative value.
 .LI
 The clock frequency, 28 MHz in this example.
 .LI
@@ -683,19 +685,18 @@
 This is pretty dry stuff.  To make it easier to understand, let's look at how we
 would set a typical VGA display with 640x480 pixels.  Sure, you can find values
 for this setup in any release of XFree86, but that doesn't mean that they're the
-optimum for \fIyour system\fP.  We want a non-flicker display, which we'll
-take to mean a vertical frequency of at least 72 Hz, and of course we don't want
-interlace.  Our multiscan monitor can handle any horizontal frequency between 15
-and 40 kHz: since we want the least flicker, we'll aim for 40 kHz.
+optimum for \fIyour system\fP.  We want a non-flicker display, which we'll take
+to mean a vertical frequency of at least 72 Hz, and of course we don't want
+interlace.  Our monitor can handle any horizontal frequency between 15 and 40
+kHz: we want the least flicker, so we'll aim for 40 kHz.
 .P
 First, we need to create our lines.  They contain 640 pixels, two porches and a
 sync pulse.  The only value we really know for sure is the number of pixels.
-How long should the porches and the sync pulses be?  If you have a good monitor
-with good documentation, it should tell you, but most monitor manufacturers
-don't seem to believe in good documentation.  When they do document the values,
-they vary significantly from monitor to monitor, and even from mode to mode:
-they're not as critical as they look.  For example, here are some typical values
-from my NEC 5D handbook:
+How long should the porches and the sync pulses be?  Good monitor documentation
+should tell you, but most monitor manufacturers don't seem to believe in good
+documentation.  The documented values vary significantly from monitor to
+monitor, and even from mode to mode: they're not as critical as they look.  Here
+are some typical values:
 .P
 Horizontal sync pulse: 1 to 4 \(*ms, front porch 0.18 to 2.1 \(*ms, back porch
 1.25 to 3.56 \(*ms.
@@ -717,10 +718,9 @@
 .P
 For our example, let's stick to 2 \(*ms per value.  We have a horizontal
 frequency of 40 kHz, or 25 \(*ms per line.  After taking off our 6 \(*ms for
-flyback control, we have only 19 \(*ms left for the display data.  In order to
-get 640 pixels in this time, we need one pixel every 19 \(di 640 \(*ms, or about 30
-ns.  This corresponds to a frequency of 33.6 MHz.  This is our desired dot
-clock.
+flyback control, we have only 19 \(*ms left for the display data.  To get 640
+pixels in this time, we need one pixel every 19 \(di 640 \(*ms, or about 30 ns.
+This corresponds to a frequency of 33.6 MHz.  This is our desired dot clock.
 .P
 The next question is: do we have a dot clock of this frequency?  Maybe.  This
 should be in your display board documentation, but I'll take a bet that it's
@@ -739,7 +739,7 @@
 .LI
 You calculate SHR by adding the number of dot clocks that elapse during the
 front porch to the value of HDE.  Recall that we decided on a front porch of 2
-\(*ms.  In this time, a 33 MHz clock will count 66 cycles.  So we add 66, right?
+\(*ms.  In this time, a 33 MHz clock counts 66 cycles.  So we add 66, right?
 Wrong.  Remember that the VGA registers count in increments of 8 pixels, so we
 need to round the width of the front porch to a multiple of 8.  In this case, we
 round it to 64, so we set SHR to 640 + 64 = 704.
@@ -751,7 +751,7 @@
 clocks\(emto EHR and get 768 + 64 = 832.
 .Le
 At this point, our vestigial mode line looks like:
-.Dx
+.Dx 1
 Modeline "640x480"   28   640 704 768 832
 .De
 Next, we need another four values to define the vertical scan.  Again, of the
@@ -762,14 +762,14 @@
 ms, a sync pulse of between 0.06 and 0.113 ms, and a back porch of between 0.54
 and 1.88 ms.  But how many lines is that?
 .P
-To figure that out, we need to know our \fIreal\fP\| horizontal frequency.  We
+To figure that out, we need to know our \fIreal\fP\/ horizontal frequency.  We
 were aiming at 40 kHz, but we made a couple of tradeoffs along the way.  The
 real horizontal frequency is the dot clock divided by the horizontal total, in
 this case 33 MHz \(di 832, which gives us 39.66 kHz\(emnot too bad.  At that
 frequency, a line lasts 1\(di39660 seconds, or just over 25 \(*ms, so our front
 porch can range between \(12 and 48 lines, our sync pulse between 2 and 5 lines,
 and the back porch between 10 and 75 lines.  Do these timings make any sense?
-No, they don't\(emthey're just values which the monitor can accept.
+No, they don't\(emthey're just values that the monitor can accept.
 .P
 To get the highest refresh rate, we can go for the lowest value in each case.
 It's difficult to specify a value of \(12, so we'll take a single line front
@@ -789,1054 +789,626 @@
 .Dx
 Modeline "640x480" 28  640 704 768 832  480 481 483 493
 .De
-.X "XF86config"
 Now we can calculate our vertical frequency, which is the horizontal frequency
 divided by the Vertical Total, or 39.66 \(di 493 kHz, which is 80.4 Hz\(emthat's
-not bad either.  By comparison, if you use the standard entry in
-\fIXF86config\fP, you will get a horizontal frequency of 31.5 kHz and a vertical
-frequency of only 60 Hz.
+not bad either.  By comparison, if you use the default value compiled into the
+server, you get a horizontal frequency of 31.5 kHz and a vertical frequency of
+only 60 Hz.
 .P
 If you know the technical details of your monitor and display board, it really
 is that simple.  This method doesn't require much thought, and it creates
-results which work.
+results that work.
+.P
+Note that the resultant mode line may not work on other monitors.  If you are
+using a laptop that you want to connect to different monitors or overhead
+display units, don't use this method.  Stick to the standard frequencies
+supplied by the X server.  Many overhead projectors understand only a very small
+number of frequencies, and the result of using a tweaked mode line is frequently
+that you can't synchronize with the display, or that it cuts off a large part of
+the image.
 .H2 "XF86Config"
 .Pn doxconfig
-.X "XF86Config"
-.X "XF86Config"
-.X "XF86Config.eg"
-.X "XF86Config"
-The \fIXF86Config\fP\| file contains several sections; these procedures will
-lead you through filling out each part.  There is a sample \fIXF86Config\fP\|
-file in \fI/usr/X11R6/lib/X11/XF86Config.eg\fP.  You can copy this to
-\fI/usr/X11R6/lib/X11/XF86Config\fP, and edit that file to your specific
-configuration.  In the following examples, we'll look at the relevant sections
-of \fIXF86Config\fP\| and discuss what might need changing.  Refer to the man
-page \fIXF86Config(5)\fP\| as you fill in your \fIXF86Config\fP\| file.  Table
-.Sref \*[Xconfig-sections] ,
-overleaf, gives you an overview of the sections in \fIXF86Config\fP.  Note that
-the X server treats lines beginning with \f(CW#\fP as comments.  You'll see many
-definitions with a \f(CW#\fP in front of them in the following examples.  You
-activate the definition by removing the \f(CW#\fP.
-.P
-Normally, you'll set up your \fIXF86Config\fP\| when you run the
-\fIxf86config\fP\| program (note the difference in character case; in UNIX,
-\fIXF86Config\fP\| and  \fIxf86config\fP\| are two different file names).  We
-looked at that in \*[chxsetup], on page
-.Sref \*[configuring-X] .
-The following discussion will apply equally well to the \fIXF86Config\fP\| file
-that you generate by this procedure.
+The main configuration file for XFree86 is called
+.File XF86Config .
+It has had a long and varied journey through the file system.  At the time of
+writing, it's located at
+.File /usr/X11R6/lib/X11/XF86Config ,
+but previously it has been put in
+.File /etc/X11/XF86Config ,
+.File -n /etc/XF86Config
+or
+.File -n /usr/X11R6/etc/X11/XF86Config ,
+and the server still looks for it in many of these places.  If you're upgrading
+a system, you should ensure that you don't have old configuration files in one
+of the alternative places.
+.P
+As we saw on page
+.Sref \*[xf86cfg] ,
+there are a couple of ways to automatically create an
+.File XF86Config
+file.  On that page we saw how to do it with
+.Command xf86cfg .
+An alternative way is to run the X server in configuration mode:
+.Dx
+# \f(CBX -configure\fP
+XFree86 Version 4.2.0 / X Window System
+(protocol Version 11, revision 0, vendor release 6600)
+Release Date: 18 January 2002
+        If the server is older than 6-12 months, or if your card is
+        newer than the above date, look for a newer version before
+        reporting problems.  (See http://www.XFree86.Org/)
+Build Operating System: FreeBSD 5.0-CURRENT i386 [ELF]
+Module Loader present
+Markers: (--) probed, (**) from config file, (==) default setting,
+         (++) from command line, (!!) notice, (II) informational,
+         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
+(==) Log file: "/var/log/XFree86.0.log", Time: Sat Apr  6 13:51:10 2002
+List of video drivers:
+        atimisc
+\fI(the list is long, and will change; it's omitted here)\fP\/
+(++) Using config file: "/root/XF86Config.new"
+
+
+Your XF86Config file is /root/XF86Config.new
+
+To test the server, run 'XFree86 -xf86config /root/XF86Config.new'
+.De
+Note that
+.Command X
+does not place the resultant configuration file in the default location.  The
+intention is that you should test it first and then move it to the final
+location when you're happy with it.  As generated above, it's good enough to run
+XFree86, but you'll possibly want to change it.  For example, it only gives you
+a single resolution, the highest it can find.  In this section we'll look at the
+configuration file in more detail, and how to change it.
+.P
+.File XF86Config
+is divided into several sections, as shown in Table
+.Sref \*[Xconfig-sections] .
+We'll look at them in the order they appear in the generated
+.File XF86Config
+file, which is not the same order as in the man page.
 .br
 .ne 10
-.TB "XF86Config sections"
-.Tn Xconfig-sections
+.Table-heading "XF86Config sections"
 .TS H
 tab(#) ;
-| l | lw67 | .
-Section#Description
--
+ l | lw58  .
+\fBSection#\fBDescription
 .TH N
+_
+ServerLayout#T{
+Describes the overall layout of the X configuration.  X can handle more than one
+display card and monitor.  This section is the key to the other sections
+T}
+.sp .4v
 Files#T{
-Sets the default font and RGB paths\(emsee page \*[XF86Config-File-section].
+Sets the default font and RGB paths.
 T}
 .sp .4v
 Server Flags#T{
-Sets a few general server options. Refer to the server manual page
-for more information about them.
+Set some global options.
 T}
 .sp .4v
-Keyboard#T{
-Sets up keyboard devices, and sets a few optional parameters\(emsee page
-\*[XF86Config-Keyboard-section]
+Module#T{
+Describes the software modules to load for the configuration.
 T}
 .sp .4v
-Pointer#T{
-Sets up the pointer devices, and sets a few optional parameters\(emsee page
-\*[XF86Config-Pointer-section]
+InputDevice#T{
+Sets up keyboards, mice and other input devices.
 T}
 .sp .4v
 Monitor#T{
-Describes your monitor to the server\(emsee page \*[XF86Config-Monitor-section]
+Describes your monitor to the server.
 T}
 .sp .4v
 Device#T{
-Describes your video hardware to the server\(emsee page
-\*[XF86Config-Device-section]
+Describes your video hardware to the server.
 T}
 .sp .4v
 Screen#T{
-Describes how to use the monitor and video hardware\(emsee page
-\*[XF86Config-Screen-section]
+Describes how to use the monitor and video hardware.
 T}
--
+_
 .TE
+.Tn Xconfig-sections
 .sp
+.H3 "The server layout"
+.Pn XF86Config-ServerLayout
+The ServerLayout section describes the relationships between the individual
+hardware components under the control of an X server.  For typical hardware,
+\f(CWX -configure\fP might generate:
+.Dx
+Section "ServerLayout"
+        Identifier     "XFree86 Configured"
+        Screen      0  "Screen0" 0 0
+        InputDevice    "Mouse0" "CorePointer"
+        InputDevice    "Keyboard0" "CoreKeyboard"
+EndSection
+.De
+This shows that the server has one screen and two input devices.  The names
+\f(CWMouse0\fP and \f(CWKeyboard0\fP suggest that they're a mouse and a
+keyboard, but any name is valid.  These entries are pointers to sections
+elsewhere in the file, which must contain definitions for \f(CWScreen0\fP,
+\f(CWMouse0\fP and \f(CWKeyboard0\fP.
+.P
+Normally you only have one screen, one mouse and one keyboard, so this section
+might seem rather unnecessary.  As we will see when we look at multiple monitor
+configurations, it's quite important to be able to describe these relationships.
 .H3 "The Files section"
 .Pn XF86Config-File-section
 .X "XF86Config, Files section"
-The \fIFiles\fP\| section of the \fIXF86Config\fP\| file contains the path to
-the RGB database file, which should never need to be changed, and the default
-font path.  You may want to add more font paths: the \f(CWFontPath\fP lines in
-your \fIXF86Config\fP\| are concatenated to form a search path.  Ensure that
-each directory listed exists and is a valid font directory.
+The \fIFiles\fP\/ section of the
+.File XF86Config
+file contains the path to the RGB database file, which should never need to be
+changed, and the default font path.  You may want to add more font paths, and
+some ports do so: the \f(CWFontPath\fP lines in your
+.File XF86Config
+are concatenated to form a search path.  Ensure that each directory listed
+exists and is a valid font directory.
 .P
-The standard \fIFiles\fP\| section looks like:
+.ne 3v
+The standard \fIFiles\fP\/ section looks like:
 .Dx
 Section "Files"
-
-# The location of the RGB database.  Note, this is the name of the
-# file minus the extension (like ".txt" or ".db").  There is normally
-# no need to change the default.
-
     RgbPath	"/usr/X11R6/lib/X11/rgb"
-
-# Multiple FontPath entries are allowed (which are concatenated together),
-# as well as specifying multiple comma-separated entries in one FontPath
-# command (or a combination of both methods)
-
+        ModulePath   "/usr/X11R6/lib/modules"
     FontPath	"/usr/X11R6/lib/X11/fonts/misc/"
-#    FontPath	"/usr/X11R6/lib/X11/fonts/Type1/"
-#    FontPath	"/usr/X11R6/lib/X11/fonts/Speedo/"
-#    FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/"
-#    FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/"
-
+        FontPath     "/usr/X11R6/lib/X11/fonts/Speedo/"
+        FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
+        FontPath     "/usr/X11R6/lib/X11/fonts/CID/"
+        FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
+        FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
+EndSection
+.De
+If you are running a high-resolution display, this sequence may be sub-optimal.
+For example, a 21" monitor running at 1600x1200 pixels has a visible display of
+approximately 16" wide and 12" high, exactly 100 \fIdpi\fP\/ (\fIdots per
+inch\fP, really pixels per inch).  As a result, you'll probably be happier with
+the 100 dpi fonts.  You can change this by swapping the last two lines in the
+section:
+.Dx
+        FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
+        FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
 EndSection
 .De
-.ne 3
-Sometimes the server complains about:
+Don't just remove the 75 dpi fonts: some fonts may be available only in the 75
+dpi directory.
+.P
+Sometimes the server complains:
 .Dx
 Can't open default font 'fixed'
 .De
-.X "mkfontdir command"
 This is almost certainly the result of an invalid entry in your font path.  Try
-running \fImkfontdir\fP\| in each directory if you are certain that each one is
-correct.  The \fIXF86Config\fP\| man page describes other parameters that may be
-in this section of the file.
-.H3 "The Keyboard section"
-.Pn XF86Config-Keyboard-section
-.X "XF86Config, Keyboard section"
-The \fIKeyboard\fP\| section specifies the keyboard protocol, the repeat rate, and
-the default mapping of some of the modifier keys:
+running
+.Command mkfontdir
+in each directory if you are certain that each one is correct.  The
+.File XF86Config
+man page describes other parameters that may be in this section of the file.
+.H3 "The ServerFlags section"
+.X "XF86Config, ServerFlags section"
+The ServerFlags section allows you to specify a number of global options.  By
+default it is not present, and you will probably not find any reason to set it.
+See the man page \fIXF86Config(5)\fP\/ for details of the options.
+.H3 "The Module section"
+.X "XF86Config, Module section"
+The \f(CWModule\fP section describes binary modules that the server loads:
 .Dx
-Section "Keyboard"
-
-    Protocol	"Standard"
-
-# when using XQUEUE, comment out the above line, and uncomment the
-# following line
-
-#    Protocol	"Xqueue"
-
-    AutoRepeat	500 5
-
-# Let the server do the NumLock processing.  This should only be required
-# when using pre-R6 clients
-#    ServerNumLock
-
-# Specifiy which keyboard LEDs can be user-controlled (eg, with xset(1))
-#    Xleds      1 2 3
-
-# To set the LeftAlt to Meta, RightAlt key to ModeShift, 
-# RightCtl key to Compose, and ScrollLock key to ModeLock:
-
-#    LeftAlt     Meta
-#    RightAlt    ModeShift
-#    RightCtl    Compose
-#    ScrollLock  ModeLock
-
+Section "Module"
+        Load  "extmod"
+        Load  "xie"
+        Load  "pex5"
+        Load  "glx"
+        Load  "GLcore"
+        Load  "dbe"
+        Load  "record"
+        Load  "type1"
 EndSection
 .De
-About the only thing you're likely to want to change are the definitions of the
-modifier keys for non-English keyboards.  See the \fIXF86Config(5)\fP\| man page
-for details.
-.H3 "The Pointer section"
-.Pn XF86Config-Pointer-section
-.X "XF86Config, Pointer section"
-The \fIPointer\fP\| section specifies the pointer protocol and device, which is
-almost always a mouse.
+We won't look at modules in more detail; see the XFree86 documentation.
+.Pn XF86Config-Module
+.H3 "The InputDevice section"
+.Pn XF86Config-InputDevice-section
+.X "XF86Config, InputDevice section"
+The \fIInputDevice\fP\/ section specifies each input device, typically mice and
+keyboards.  Older versions of XFree86 had separate \f(CWMouse\fP and
+\f(CWKeyboard\fP sections to describe these details.  The default
+\f(CWXF86Config\fP looks something like this:
 .Dx
-Section "Pointer"
-
-    Protocol	"Microsoft"
-    Device	"/dev/com1"
-
-# When using XQUEUE, comment out the above two lines, and uncomment
-# the following line.
-
-#    Protocol	"Xqueue"
-
-# Baudrate and SampleRate are only for some Logitech mice
-
-#    BaudRate	9600
-#    SampleRate	150
-
-# Emulate3Buttons is an option for 2-button Microsoft mice
-# Emulate3Timeout is the timeout in milliseconds (default is 50ms)
-
-#    Emulate3Buttons
-#    Emulate3Timeout	50
-
-# ChordMiddle is an option for some 3-button Logitech mice
-
-#    ChordMiddle
+Section "InputDevice"
+        Identifier  "Keyboard0"
+        Driver      "keyboard"
+EndSection
 
+Section "InputDevice"
+        Identifier  "Mouse0"
+        Driver      "mouse"
+        Option      "Protocol" "auto"
+        Option      "Device" "/dev/mouse"
 EndSection
 .De
-These values are defaults, and many are either incorrect for FreeBSD (for
-example the device name \fI/dev/com1\fP\|) or do not apply at all (for example
-\f(CWXqueue\fP).  If you are configuring manually, select one \f(CWProtocol\fP
-and one \f(CWDevice\fP entry from the following selection.  If you must use a
-two-button mouse, uncomment the keyword \f(CWEmulate3Buttons\fP\(emin this mode,
-pressing both mouse buttons simultaneously within \f(CWEmulate3Timeout\fP
-milliseconds causes the server to report a middle button press.
-.Dx
-Section "Pointer"
-
-    Protocol	"Microsoft"	\fIfor Microsoft protocol mice\fP\|
-    Protocol    "MouseMan"		\fIfor Logitech mice\fP\|
-    Protocol    "PS/2"		\fIfor a PS/2 mouse\fP\|
-    Protocol    "Busmouse"		\fIfor a bus mouse\fP\|
-
-    Device	"/dev/ttyd0"		\fIfor a mouse on the first serial port\fP\|
-    Device	"/dev/ttyd1"		\fIfor a mouse on the second serial port\fP\|
-    Device	"/dev/ttyd2"		\fIfor a mouse on the third serial port\fP\|
-    Device	"/dev/ttyd3"		\fIfor a mouse on the fourth serial port\fP\|
-    Device	"/dev/psm0"		\fIfor a PS/2 mouse\fP\|
-    Device	"/dev/mse0"		\fIfor a bus mouse\fP\|
-
-    Emulate3Buttons			\fIonly for a two-button mouse\fP\|
-
+There's not much to be said for the keyboard.  Previous versions of XFree86
+allowed you to set things like \fINumLock\fP\/ handling and repeat rate, but the
+former is no longer needed, and the latter is easier to handle with the
+.Command xset
+program.
+.P
+Mice are still not as standardized as keyboards, so you still need a
+\f(CWProtocol\fP line and a device name.  The defaults shown here are correct
+for most modern mice; the mouse driver can detect the mouse type correctly.  If
+you're using the mouse daemon,
+.Daemon moused ,
+change this entry to the
+.Daemon moused
+device,
+.Device sysmouse .
+.P
+If you're using a serial mouse or one with only two buttons, \fIand\fP\/ if
+you're not using
+.Daemon moused ,
+you need to change the device entries and specify the \f(CWEmulate3Buttons\fP
+option.  That's all described in the man page, but in general it's easier to use
+.Daemon moused .
+.H3 "The Monitor section"
+.Pn XF86Config-Monitor-section
+.X "XF86Config, Monitor section"
+Next comes the description of the monitor.  Modern monitors can identify
+themselves to the system.  In that case, you get a section that looks like
+this:
+.Dx
+Section "Monitor"
+        Identifier   "Monitor0"
+        VendorName   "IBM"
+        ModelName    "P260"
+        HorizSync    30.0 - 121.0
+        VertRefresh  48.0 - 160.0
+.De
+This tells the server that the monitor is an IBM P260, that it can handle
+horizontal frequencies between 30 kHz and 121 kHz, and vertical frequencies
+between 48 Hz and 160 Hz.  Less sophisticated monitors don't supply this
+information, so you might end up with an entry like this:
+.Dx
+Section "Monitor"
+        Identifier   "Monitor0"
+        VendorName   "Monitor Vendor"
+        ModelName    "Monitor Model"
 EndSection
 .De
-You'll notice that the protocol name does not always match the manufacturer's
-name.  In particular, the \fILogitech\fP\| protocol only applies to older
-Logitech mice.  The newer ones use either the MouseMan or Microsoft protocols.
-Nearly all modern serial mice run one of these two protocols, and most run both.
-.P
-If you are using a bus mouse or a PS/2 mouse, make sure that the device driver
-is included in the kernel.  The \f(CWGENERIC\fP kernel contains drivers for both
-mice, but the PS/2 driver is disabled.  Use UserConfig (see page \*[UserConfig])
-to enable it.
+This may seem like no information at all, but in fact it does give the
+identifier.  Before you use it, you should add at least the horizontal and
+vertical frequency range, otherwise the server assumes it's a standard (and
+obsolete) VGA monitor capable of only 640x480 resolution.
+.P
+This is also the place where you can add mode lines.  For example, if you have
+created a mode line as described in the first part of this chapter, you should
+add it here:
+.Dx
+Section "Monitor"
+        Identifier   "right"
+        VendorName   "iiyama"
+        ModelName    "8221T"
+        HorizSync    24.8 - 94.0
+        VertRefresh  50.0 - 160.0
+
+ModeLine  "640x480"    73   640  672  768  864    480  488  494  530
+# 62 Hz!
+ModeLine  "800x600"   111   800  864  928 1088    600  604  610  640
+# 143 Hz
+ModeLine  "1024x768"  165  1024 1056 1248 1440    768  771  781  802
+# 96 Hz
+ModeLine  "1280x1024" 195  1280 1312 1440 1696   1024 1031 1046 1072 -hsync -vsync
+# 76 Hz
+ModeLine  "1600x1200" 195  1600 1616 1808 2080   1200 1204 1207 1244 +hsync +vsync
+# 56 Hz!
+ModeLine  "1920x1440" 200  1920 1947 2047 2396   1440 1441 1444 1483 -hsync +vsync
+# 61 Hz
+ModeLine  "1920x1440" 220  1920 1947 2047 2448   1440 1441 1444 1483 -hsync +vsync
+        EndSection
+.De
+It's possible to have multiple mode lines for a single frequency, and this even
+makes sense.  The examples for 1920x1440 above have different pixel clocks.  If
+you use this monitor with a card with a pixel clock that only goes up to 200
+MHz, the server chooses the first mode line.  If you use a card with up to 250
+MHz pixel clock, it uses the second and gets a better page refresh rate.
+.P
+The X server has a number of built-in mode lines, so it's quite possible to have
+a configuration file with no mode lines at all.  The names correspond to the
+resolutions, and there can be multiple mode lines with the same name.  The
+server chooses the mode line with the highest frequency compatible with the
+hardware.
 .H3 "The Device section"
 .X "XF86Config, Device section"
 .Pn XF86Config-Device-section
-The \fIDevice\fP\| section describes the video hardware.  You can specify multiple
-device sections, each section describing a single graphics board.  Here are some
-typical examples:
+The \fIDevice\fP\/ section describes the video display board:
 .Dx
-# Any number of graphics device sections may be present
-
 Section "Device"
-    Identifier	"Generic VGA"
-    VendorName	"Unknown"
-    BoardName	"Unknown"
-    Chipset	"generic"
-#    VideoRam	256
-#    Clocks	25.2 28.3
-EndSection
-
-Section "Device"
-    # SVGA server auto-detected chipset
-    Identifier	"Generic SVGA"
-    VendorName	"Unknown"
-    BoardName	"Unknown"
-EndSection
-
-# Section "Device"
-#    Identifier	"Any Trident TVGA 9000"
-#    VendorName	"Trident"
-#    BoardName	"TVGA 9000"
-#    Chipset	"tvga9000"
-#    VideoRam	512
-#    Clocks	25 28 45 36 57 65 50 40 25 28 0 45 72 77 80 75
-# EndSection
-
-# Section "Device"
-#    Identifier	"Actix GE32+ 2MB"
-#    VendorName	"Actix"
-#    BoardName	"GE32+"
-#    Ramdac	"ATT20C490"
-#    Dacspeed	110
-#    Option	"dac_8_bit"
-#    Clocks	 25.0  28.0  40.0   0.0  50.0  77.0  36.0  45.0
-#    Clocks	130.0 120.0  80.0  31.0 110.0  65.0  75.0  94.0
-# EndSection
-.De
-Be sure to read the server manual pages and the chipset-specific \fIREADME\fP\|
-files for any non-generic information that may apply to your setup.
-.P
-To create a \fIDevice\fP\| section you need to collect the data for your hardware,
-and make some configuration decisions.  The hardware data you need is:
-.Ls B
-.LI
-Chipset
-.LI
-Amount of video memory
-.LI
-Dot-clocks available or clock chip used (if programmable)
-.LI
-Ramdac type (for some servers)
-.Le
-.X "XF86Config, Chipset specification"
-The server can usually determine this information on its own, but it is best to
-fully specify things in the \fIXF86Config\fP\| file, so that no mistakes are made.
-The \fIChipset\fP\| is one of the keyword strings for a configured driver\(emyou
-can display it with
-.Dx
-$ \f(CBX -showconfig\fP
-XFree86 Version 3.3.3.1 / X Window System
-(protocol Version 11, revision 0, vendor release 6300)
-Release Date: December 29 1998
-        If the server is older than 6-12 months, or if your card is newer
-        than the above date, look for a newer version before reporting
-        problems.  (see http://www.XFree86.Org/FAQ)
-Operating System: FreeBSD 3.0-CURRENT i386 [ELF] 
-Configured drivers:
-  SVGA: server for SVGA graphics adaptors (Patchlevel 0):
-      NV1, STG2000, RIVA128, RIVATNT, ET4000, ET4000W32, ET4000W32i,
-      ET4000W32i_rev_b, ET4000W32i_rev_c, ET4000W32p, ET4000W32p_rev_a,
-      ET4000W32p_rev_b, ET4000W32p_rev_c, ET4000W32p_rev_d, ET6000, ET6100,
-      et3000, pvga1, wd90c00, wd90c10, wd90c30, wd90c24, wd90c31, wd90c33,
-      gvga, ati, sis86c201, sis86c202, sis86c205, sis86c215, sis86c225,
-      sis5597, sis5598, sis6326, tvga8200lx, tvga8800cs, tvga8900b,
-      tvga8900c, tvga8900cl, tvga8900d, tvga9000, tvga9000i, tvga9100b,
-      tvga9200cxr, tgui9400cxi, tgui9420, tgui9420dgi, tgui9430dgi,
-      tgui9440agi, cyber9320, tgui9660, tgui9680, tgui9682, tgui9685,
-      cyber9382, cyber9385, cyber9388, cyber9397, cyber9520, 3dimage975,
-      3dimage985, clgd5420, clgd5422, clgd5424, clgd5426, clgd5428,
-      clgd5429, clgd5430, clgd5434, clgd5436, clgd5446, clgd5480, clgd5462,
-      clgd5464, clgd5465, clgd6205, clgd6215, clgd6225, clgd6235, clgd7541,
-      clgd7542, clgd7543, clgd7548, clgd7555, clgd7556, ncr77c22, ncr77c22e,
-      cpq_avga, mga2064w, mga1064sg, mga2164w, mga2164w AGP, mgag200,
-      mgag100, oti067, oti077, oti087, oti037c, al2101, ali2228, ali2301,
-      ali2302, ali2308, ali2401, cl6410, cl6412, cl6420, cl6440, video7,
-      ark1000vl, ark1000pv, ark2000pv, ark2000mt, mx, realtek, s3_virge,
-      AP6422, AT24, AT3D, s3_svga, NM2070, NM2090, NM2093, NM2097, NM2160,
-      NM2200, ct65520, ct65525, ct65530, ct65535, ct65540, ct65545, ct65546,
-      ct65548, ct65550, ct65554, ct65555, ct68554, ct69000, ct64200,
-      ct64300, mediagx, V1000, V2x00, p9100, spc8110, generic
-.De
-Note that the operating system is reported as \f(CWFreeBSD 3.0-CURRENT\fP.  This
-is the release of FreeBSD under which the server was built, not necessarily the
-release for which it was intended.  In particular, it does not mean that it is
-out of date, or that you have accidentally installed the wrong version.
-.P
-Only some of the accelerated servers currently have chipset drivers.  The amount
-of memory is specified in KBytes, so you specify 1 MB of memory as 1024.
-.P
-.X "devices, XF86Config entry"
-.X "modeDB.txt"
-.X "AccelCards"
-The dot-clocks are the trickiest part of board configuration.  Fortunately a
-large database of collected dot-clocks is available.  You can find a list of
-Device entries for some graphics boards in the file
-\fI/usr/X11R6/lib/X11/doc/Devices\fP.  If you find one for your board, you can
-start with that.  Also, the first part of the file
-\fI/usr/X11R6/lib/X11/doc/modeDB.txt\fP\| lists information for a myriad of SVGA
-boards.  For accelerated boards, you can also look in the file
-\fI/usr/X11R6/lib/X11/doc/AccelCards\fP.  If you find your board, copy the
-numbers from the database to the Clocks line in your \fIXF86Config\fP\| file,
-exactly as they appear in the database, without sorting, and leaving any
-duplicates.  Note that some of the newer accelerated boards use a programmable
-clock generator, in which case a ClockChip line is used in your
-\fIXF86Config\fP\| file to identify the type of clock generator.  For example,
-for a #9 GXe board you would specify
-.Dx
-ClockChip "icd2061a"
-.De
-.P
-If you can't find a listing for your board, you can attempt to have the server
-detect them.  Run the command: 
-.Dx
-$ \f(CBX -probeonly >/tmp/out 2>&1		\fIfor sh, ksh, bash, or zsh\fR
-% \f(CBX -probeonly >&/tmp/out			\fIfor csh or tcsh\fR
-.De
-Be sure that the \fIXF86Config\fP\| file does not contain a Clocks line at this
-point.  Running this will cause your monitor to freak out for a couple of
-seconds, as the server cycles through the clocks rapidly.  It should not damage
-your monitor, but some newer monitors may shut themselves off because things may
-go out of spec.  Anyhow, when this gets done, look in the file \fI/tmp/out\fP\|
-for the detected dot-clocks.  Copy these to the Clocks line in your
-\fIXF86Config\fP\| file, exactly as they appear in \fI/tmp/out\fP.  Don't sort
-them or rearrange them in any way.
-.P
-Your board may have a programmable clock generator.  A symptom of this will be a
-printout of only 2 or 3 clock values, with the rest all zeros.  If you run into
-this, and your board is not listed in the databases, contact the XFree86 team
-for help, or post a message to \f(CWcomp.windows.x.i386unix\fP.
-.P
-Some servers (S3 and AGX) require you to identify the type and speed of the
-RAMDAC your board uses in order to get the most out of the hardware.  This is
-done by adding entries \f(CWRamdac\fP and \f(CWDacSpec\fP.  For details of the
-supported RAMDACs, refer to the appropriate server manual page.  Previous
-versions of XFree86 specified the RAMDAC type with an Option flag.
-.P
-You may need to specify some option flags for your hardware.  The server manual
-pages will describe these options, and the chipset-specific \fIREADME\fP\| files
-will tell you if any are required for your board.
-.H3 "Configuring the Monitor and its Modes"
-.X "VideoModes.doc"
-Configuring monitor modes can be a trying experience because of the lack of
-standardization in monitor hardware.  The XFree86 project has attempted to
-simplify this by collecting databases of specific monitor information, and
-assembling a set of generic modes that should get pretty much any monitor up and
-functional.  For all the gory details of mode generation and tuning, refer to
-the file \fI/usr/X11R6/lib/X11/doc/VideoModes.doc\fP.
-.H3 "The Monitor section"
-.Pn XF86Config-Monitor-section
-.X "XF86Config, Monitor section"
-.X "Monitors, documentation"
-The monitor specs and video modes are described in the \fIMonitor\fP\| sections in
-the \fIXF86Config\fP\| file:
-.Dx
-# Any number of monitor sections may be present
-
-Section "Monitor"
-
-    Identifier	"Generic Monitor"
-    VendorName	"Unknown"
-    ModelName	"Unknown"
-
-# HorizSync is in kHz unless units are specified.
-# HorizSync may be a comma separated list of discrete values, or a
-# comma separated list of ranges of values.
-# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
-# USER MANUAL FOR THE CORRECT NUMBERS.
-
-    HorizSync   31.5  # typical for a single frequency fixed-sync monitor
-
-#    HorizSync	30-64         # multisync
-#    HorizSync	31.5, 35.2    # multiple fixed sync frequencies
-#    HorizSync	15-25, 30-50  # multiple ranges of sync frequencies
-
-# VertRefresh is in Hz unless units are specified.
-# VertRefresh may be a comma separated list of discrete values, or a
-# comma separated list of ranges of values.
-# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
-# USER MANUAL FOR THE CORRECT NUMBERS.
-
-    VertRefresh 60  # typical for a single frequency fixed-sync monitor
-
-#    VertRefresh	50-100        # multisync
-#    VertRefresh	60, 65        # multiple fixed sync frequencies
-#    VertRefresh	40-50, 80-100 # multiple ranges of sync frequencies
-
-# Modes can be specified in two formats.  A compact one-line format, or
-# a multi-line format.
-
-# A generic VGA 640x480 mode (hsync = 31.5kHz, refresh = 60Hz)
-# These two are equivalent
-
-#    ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525
-
-    Mode "640x480"
-        DotClock	25.175
-        HTimings	640 664 760 800
-        VTimings	480 491 493 525
-    EndMode
-
-# These two are equivalent
-
-#    ModeLine "1024x768i" 45 1024 1048 1208 1264 768 776 784 817 Interlace
-
-#    Mode "1024x768i"
-#        DotClock	45
-#        HTimings	1024 1048 1208 1264
-#        VTimings	768 776 784 817
-#        Flags		"Interlace"
-#    EndMode
-
+        ### Available Driver options are:-
+        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
+        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
+        ### [arg]: arg optional
+        #Option     "SWcursor"                  # [<bool>]
+        #Option     "HWcursor"                  # [<bool>]
+        #Option     "PciRetry"                  # [<bool>]
+        #Option     "SyncOnGreen"               # [<bool>]
+        #Option     "NoAccel"                   # [<bool>]
+        #Option     "ShowCache"                 # [<bool>]
+        #Option     "Overlay"                   # [<str>]
+        #Option     "MGASDRAM"                  # [<bool>]
+        #Option     "ShadowFB"                  # [<bool>]
+        #Option     "UseFBDev"                  # [<bool>]
+        #Option     "ColorKey"                  # <i>
+        #Option     "SetMclk"                   # <freq>
+        #Option     "OverclockMem"              # [<bool>]
+        #Option     "VideoKey"                  # <i>
+        #Option     "Rotate"                    # [<str>]
+        #Option     "TexturedVideo"             # [<bool>]
+        #Option     "Crtc2Half"                 # [<bool>]
+        #Option     "Crtc2Ram"                  # <i>
+        #Option     "Int10"                     # [<bool>]
+        #Option     "AGPMode"                   # <i>
+        #Option     "DigitalScreen"             # [<bool>]
+        #Option     "TV"                        # [<bool>]
+        #Option     "TVStandard"                # [<str>]
+        #Option     "CableType"                 # [<str>]
+        #Option     "NoHal"                     # [<bool>]
+        #Option     "SwappedHead"               # [<bool>]
+        #Option     "DRI"                       # [<bool>]
+        Identifier  "Card0"
+        Driver      "mga"
+        VendorName  "Matrox"
+        BoardName   "MGA G200 AGP"
+        BusID       "PCI:1:0:0"
 EndSection
 .De
-To create a Monitor section, you need to know your monitor's specifications, in
-particular its video bandwidth and what range of horizontal sync and vertical
-sync rates it supports.  If you can't find this information in the monitor's
-user manual, check the file \fI/usr/X11R6/lib/X11/doc/Monitors\fP\| to see if it
-has an entry for your monitor.  The \fIXF86Config\fP\| man page describes how to
-enter this information into the Monitor section.
-.P
-Next, you need to provide a set of video modes that are suitable for the
-monitor.  The first step is to check in the \fIMonitors\fP\| and \fImodeDB.txt\fP\|
-files to see if there is a listing of modes for your specific monitor.  If there
-is, copy those modes to the Monitor section of your \fIXF86Config\fP\| file.
-Verify that there is a clock listed on the Clocks line in your \fIXF86Config\fP\|
-that matches the dot clock in the 2nd parameter of each mode line; delete any
-mode line that does not have a matching clock on your board.  If you still have
-modes left, you are in good shape.
-.P
-If you don't find any specific modes, or need more modes for the resolutions you
-want to use, refer to the Generic Video Modes listing in the file
-\fI/usr/X11R6/lib/X11/doc/README.Config\fP.  Match the mode specification
-against your monitor's specifications; pick the highest-refresh mode that is
-within specs, and make sure you have a matching dot-clock on your Clocks line.
-Try the VESA modes before any corresponding alternate mode setting.  Copy the
-mode specification to the Monitor section of your \fIXF86Config\fP\| file.  Note
-that these modes are likely not optimal; they may not be sized perfectly, or may
-not be correctly centered.  But they should get you up and running.  If you want
-to tune the mode to your monitor, you can read the section \fIFixing Problems
-with the Image\fP\| in \fIVideoModes.doc\fP.
-.P
-A note before you are done.  If the same mode name occurs more than once in the
-Monitor section of the \fIXF86Config\fP\| file, the server will use the first mode
-with a matching clock.  It is generally considered a bad idea to have more than
-one mode with the same name in your \fIXF86Config\fP\| file.
+This example shows a Matrox G200 AGP display board.  It includes a number of
+options that you can set by removing the comment character (\f(CW#\fP).  Many
+of these options are board dependent, and none of them are required.  See the X
+documentation for more details.
+.P
+Note particularly the last line, \f(CWBusID\fP.  This is a hardware-related
+address that tells the X server where to find the display board.  If you move
+the board to a different PCI slot, the address will probably change, and you
+will need to re-run \fIX -configure\fP\/ to find the new bus ID.
+.P
+If your display board is older, much of this information will not be available,
+and you'll have to add it yourself.  Unlike older monitors, it's hardly worth
+worrying about older boards, though: modern boards have become extremely cheap,
+and they're so much faster than older boards that it's not worth the trouble.
 .H3 "The Screen section"
 .Pn XF86Config-Screen-section
 .X "XF86Config, Screen section"
-Once you have given a description of your monitor and graphics hardware you need
-to specify how they are to be used by the servers.  This is the purpose of the
-\fIScreen\fP\| sections in the \fIXF86Config\fP\| file:
+The final section is the Screen section, which describes the display on a
+monitor.  The default looks something like this:
 .Dx
-# The colour SVGA server
 Section "Screen"
-    Driver	"svga"
-    Device	"Generic SVGA"
-    Monitor	"Generic Monitor"
-    Subsection "Display"
+        Identifier "Screen0"
+        Device     "Card0"
+        Monitor    "Monitor0"
+        SubSection "Display"
+                Depth     1
+        EndSubSection
+        SubSection "Display"
+                Depth     4
+        EndSubSection
+        SubSection "Display"
         Depth	    8
-        Modes	    "640x480"
-        ViewPort    0 0
-        Virtual     800 600
-    EndSubsection
+        EndSubSection
+        SubSection "Display"
+                Depth     15
+        EndSubSection
+        SubSection "Display"
+                Depth     16
+        EndSubSection
+        SubSection "Display"
+                Depth     24
+        EndSubSection
 EndSection
-
-# The 16-colour VGA server
-Section "Screen"
-    Driver	"vga16"
-    Device	"Generic VGA"
-    Monitor	"Generic Monitor"
-    Subsection "Display"
-        Modes	    "640x480"
-        ViewPort    0 0
-        Virtual     800 600
-    EndSubsection
-EndSection
-
-# The Mono server
+.De
+The first three lines describe the relationship between the screen display, the
+video board that creates it, and the monitor on which it is displayed.  Next
+come a number of subsections describing the possible bit depths that the screen
+may have.
+.Pn pixel-depth
+For each display depth, you can specify which mode lines you wish to use.
+Modern display hardware has plenty of memory, so you'll probably not want to
+restrict the display depth.  On the other hand, you may want to have multiple
+mode lines.  Your display card and monitor are good enough to display 2048x1536
+at 24 bits per pixel, but occasionally you'll get images (in badly designed web
+pages, for example) so miniscule that you'll want to zoom in, maybe going all
+the way back to 640x480 in extreme cases.  You can toggle through the available
+resolutions with the key combinations \fBCtrl\fP-\fBAlt\fP-\fBNumeric\ +\fP and
+\fBCtrl\fP-\fBAlt\fP-\fBNumeric\ -\fP.  You're probably not interested in pixel
+depths lower than 640x480, so your Screen section might look like:
+.Dx
 Section "Screen"
-    Driver	"vga2"
-    Device	"Generic VGA"
-    Monitor	"Generic Monitor"
-    Subsection "Display"
-        Modes	    "640x480"
-        ViewPort    0 0
-        Virtual     800 600
-    EndSubsection
+        Identifier "Screen0"
+        Device     "Card0"
+        Monitor    "Monitor0"
+        DefaultDepth    24
+        SubSection "Display"
+                Depth     24
+                Modes     "2048x1536" "1600x1200"  "1024x768"  "640x480"
+        EndSubSection
 EndSection
-
-# The accelerated servers (S3, Mach32, Mach8, 8514, P9000, AGX, W32)
-# Section "Screen"
-#     Driver	"accel"
-#     Device	"Actix GE32+ 2MB"
-#     Monitor	"Generic Monitor"
-#     Subsection  "Display"
-#         Depth	    8
-#         Modes	    "640x480"
-#         ViewPort    0 0
-#         Virtual	    1280 1024
-#     EndSubsection
-#     SubSection "Display"
-#         Depth	    16
-#         Weight	    565
-#         Modes	    "640x480"
-#         ViewPort    0 0
-#         Virtual	    1024 768
-#     EndSubsection
-# EndSection
-.De
-Supply a Screen section for each of the server driver types you will be using.
-The driver types are \f(CWSVGA\fP (\fIXF86_SVGA\fP\|), \f(CWVGA16\fP
-(\fIXF86_VGA16\fP\|), \f(CWVGA2\fP (\fIXF86_Mono\fP\|), \f(CWMONO\fP
-(\fIXF86_Mono\fP, \fIXF86_VGA16\fP\|), and \f(CWACCEL\fP (\fIXF86_S3\fP,
-\fIXF86_Mach32\fP, \fIXF86_Mach8\fP, \fIXF86_Mach64\fP, \fIXF86_8514\fP,
-\fIXF86_P9000\fP, \fIXF86_AGX\fP, and \fIXF86_W32\fP\|).  Each Screen section
-specifies which Monitor description and Device description are to be used.
-.P
-The Screen sections include one or more \fIDisplay\fP\| subsections.  One
-Display subsection may be provided for each pixel depth (the number of bits per
-pixel) that the server supports.  In the Display subsection you can specify the
-size of the virtual screen the server will use.  The virtual screen allows you
-to have a \fIroot window\fP\| larger than can be displayed on your monitor.  For
-example, you can have an 800x600 display, but a 1280x1024 virtual size.  Use the
-keyword \f(CWVirtual\fP to specify this size.  Note that many of the new
-accelerated servers use non-displayed memory for caching.  It is not desirable
-to use all of your memory for virtual display, as this leaves none for caching,
-and this can cost as much as 30-40% of your server performance.
-.P
-The last thing you specify in Display subsection are the display modes, the
-physical display resolutions that the server will use.  The name is arbitrary,
-but must match something in the appropriate \fIMonitor\fP\| section.  By
-convention, these names are the display resolution (for example
-\f(CW1024x768\fP), but this is not a requirement.  You can list as many as
-desired; the first is the initial display resolution, and you can cycle through
-the list with \fBCtrl-Alt-Keypad+\fP or \fBCtrl-Alt-Keypad-\fP hotkey sequences.
-..endif
-..if finished
-.P
-That's it.  Now you're ready to test out your new XFree86 installation.
-.H3 "Testing the results"
-The results of an automatic installation may be less than optimal.  For example,
-after running \fIxf86config\fP\| with an old ET4000 board and an ADI 5AP monitor,
-which is capable of horizontal frequencies between 30 and 64 kHz, I got very bad
-flicker at a resolution of 800x600, and the 1024x768 display was even worse and
-seemed to be constantly moving.  This phenomenon is the result of interlacing,
-an indication that the server thinks it can't produce a high enough frequency.
-Looking at the log file, I found:
-.Dx
-XFree86 Version 3.1.2 / X Window System
-(protocol Version 11, revision 0, vendor release 6000)
-Operating System: FreeBSD \*[Fver]
-Configured drivers:
-  SVGA: server for 8-bit colour SVGA (Patchlevel 0):
-      et4000, et4000w32, et4000w32i, et4000w32p, et3000, pvga1, wd90c00,
-      wd90c10, wd90c30, wd90c24, wd90c31, wd90c33, gvga, vgawonder,
-      tvga8800cs, tvga8900b, tvga8900c, tvga8900cl, tvga9000, clgd5420,
-      clgd5422, clgd5424, clgd5426, clgd5428, clgd5429, clgd5430, clgd5434,
-      clgd5436, clgd6205, clgd6215, clgd6225, clgd6235, ncr77c22, ncr77c22e,
-      cpq_avga, oti067, oti077, oti087, mx, al2101, ali2228, ali2301,
-      ali2302, ali2308, ali2401, cl6410, cl6412, cl6420, cl6440, video7,
-      ct65520, ct65530, ct65540, ct65545, ark1000vl, ark1000pv, ark2000pv,
-      realtek, generic
-Using syscons driver with X support (version 2.0)
-(using VT number 10)
-
-XF86Config: /etc/XF86Config
-(**) stands for supplied, (--) stands for probed/default values
-(**) Mouse: type: MouseMan, device: /dev/ttyd0, baudrate: 1200,
-       Chorded middle button
-(**) SVGA: Graphics device ID: "Old ET4000"
-(**) SVGA: Monitor ID: "5AP"
-(--) SVGA: Mode "1280x1024" needs hsync freq of 78.86 kHz. Deleted.
-(--) SVGA: Mode "1280x1024" needs hsync freq of 81.13 kHz. Deleted.
-(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Ty
-pe1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6
-/lib/X11/fonts/100dpi/"
-(--) SVGA: ET4000: Initial hibit state: high
-(--) SVGA: chipset:  et4000
-(--) SVGA: videoram: 1024k
-(--) SVGA: clocks:  25.25  28.32  32.64  36.11  40.12  45.01  31.53  37.74
-(--) SVGA: clocks:  50.51  56.66  65.30  72.25  80.29  90.07  63.09  75.51
-(--) SVGA: Maximum allowed dot-clock: 90.000 MHz
-(**) SVGA: Mode "640x480": mode clock =  31.500, clock used =  31.530
-(**) SVGA: Mode "800x600": mode clock =  36.000, clock used =  36.110
-(**) SVGA: Mode "1024x768": mode clock =  44.900, clock used =  45.010
-(**) SVGA: Virtual resolution set to 1152x900
-(--) SVGA: SpeedUp code selection modified because virtualX != 1024
-(--) SVGA: ET4000: SpeedUps selected (Flags=0xf)
-access control disabled, clients can connect from any host
-.De
-The problem here is that the \fIXF86Config\fP\| file doesn't have any suitable
-mode line entries.  In this case, the mode lines for 80x600 and 1024x768 were:
-.Dx
-# 800x600 @ 56 Hz, 35.15 kHz hsync
-ModeLine "800x600"     36     800  824  896 1024   600  601  603  625
-\fIThis is the 800x600 resolution the server chose\fP\|
-# 1024x768 @ 87 Hz interlaced, 35.5 kHz hsync
-Modeline "1024x768"    44.9  1024 1048 1208 1264   768  776  784  817 Interlace
-\fIThis is the 1024x768 resolution the server chose\fP\|
-
-# 800x600 @ 60 Hz, 37.8 kHz hsync
-Modeline "800x600"     40     800  840  968 1056   600  601  605  628 +hsync +vsync
-
-# 800x600 @ 72 Hz, 48.0 kHz hsync
-Modeline "800x600"     50     800  856  976 1040   600  637  643  666 +hsync +vsync
-# 1024x768 @ 60 Hz, 48.4 kHz hsync
-Modeline "1024x768"    65    1024 1032 1176 1344   768  771  777  806 -hsync -vsync
-
-# 1024x768 @ 70 Hz, 56.5 kHz hsync
-Modeline "1024x768"    75    1024 1048 1184 1328   768  771  777  806 -hsync -vsync
-
-# 1024x768 @ 76 Hz, 62.5 kHz hsync
-Modeline "1024x768"    85    1024 1032 1152 1360   768  784  787  823
-.De
-
-
-
-xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"
-X connection to :0.0 broken (explicit kill or server shutdown).
-xinit:  connection to X server lost.
-
-
-
-
-.H2 "Generic Video Modes"
-.Dx
-______________________________________________________________________
-#
-#  Mode       Refresh  Hor. Sync  Dot-clock  Interlaced?  VESA?
-#  ------------------------------------------------------------
-#  640x480     60Hz      31.5k     25.175M       No         No
-#  640x480     60Hz      31.5k     25.175M       No         No
-#  640x480     63Hz      32.8k     28.322M       No         No
-#  640x480     70Hz      36.5k     31.5M         No         No
-#  640x480     72Hz      37.9k     31.5M         No        Yes
-#  800x600     56Hz      35.1k     36.0M         No        Yes
-#  800x600     56Hz      35.4k     36.0M         No         No
-#  800x600     60Hz      37.9k     40.0M         No        Yes
-#  800x600     60Hz      37.9k     40.0M         No         No
-#  800x600     72Hz      48.0k     50.0M         No        Yes
-#  1024x768i   43.5Hz    35.5k     44.9M        Yes         No
-#  1024x768    60Hz      48.4k     65.0M         No        Yes
-#  1024x768    60Hz      48.4k     62.0M         No         No
-#  1024x768    70Hz      56.5k     75.0M         No        Yes
-#  1024x768    70Hz      56.25k    72.0M         No         No
-#  1024x768    76Hz      62.5k     85.0M         No         No
-#  1280x1024i  44Hz      51kHz     80.0M        Yes         No
-#  1280x1024i  44Hz      47.6k     75.0M        Yes         No
-#  1280x1024   59Hz      63.6k    110.0M         No         No
-#  1280x1024   61Hz      64.24k   110.0M         No         No
-#  1280x1024   74Hz      78.85k   135.0M         No         No
-
-#
-# 640x480@60Hz Non-Interlaced mode
-# Horizontal Sync = 31.5kHz
-# Timing: H=(0.95us, 3.81us, 1.59us), V=(0.35ms, 0.064ms, 1.02ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"640x480"     25.175  640  664  760  800    480  491  493  525
-
-#
-# Alternate 640x480@60Hz Non-Interlaced mode
-# Horizontal Sync = 31.5kHz
-# Timing: H=(1.27us, 3.81us, 1.27us) V=(0.32ms, 0.06ms, 1.05ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"640x480"     25.175  640  672  768  800    480  490  492  525
-
-#
-# 640x480@63Hz Non-Interlaced mode (non-standard)
-# Horizontal Sync = 32.8kHz
-# Timing: H=(1.41us, 1.41us, 5.08us) V=(0.24ms, 0.092ms, 0.92ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"640x480"     28.322  640  680  720  864    480  488  491  521
-
-#
-# 640x480@70Hz Non-Interlaced mode (non-standard)
-# Horizontal Sync = 36.5kHz
-# Timing: H=(1.27us, 1.27us, 4.57us) V=(0.22ms, 0.082ms, 0.82ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"640x480"     31.5    640  680  720  864    480  488  491  521
-
-#
-# VESA 640x480@72Hz Non-Interlaced mode
-# Horizontal Sync = 37.9kHz
-# Timing: H=(0.76us, 1.27us, 4.06us) V=(0.24ms, 0.079ms, 0.74ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"640x480"     31.5    640  664  704  832    480  489  492  520
-
-#
-# VESA 800x600@56Hz Non-Interlaced mode
-# Horizontal Sync = 35.1kHz
-# Timing: H=(0.67us, 2.00us, 3.56us) V=(0.03ms, 0.063ms, 0.70ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"800x600"     36      800  824  896 1024    600  601  603  625
-
-#
-# Alternate 800x600@56Hz Non-Interlaced mode
-# Horizontal Sync = 35.4kHz
-# Timing: H=(0.89us, 4.00us, 1.11us) V=(0.11ms, 0.057ms, 0.79ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"800x600"     36      800  832  976 1016    600  604  606  634
-
-#
-# VESA 800x600@60Hz Non-Interlaced mode
-# Horizontal Sync = 37.9kHz
-# Timing: H=(1.00us, 3.20us, 2.20us) V=(0.03ms, 0.106ms, 0.61ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"800x600"     40      800  840  968 1056    600  601  605  628 +hsync +vsync
-
-#
-# Alternate 800x600@60Hz Non-Interlaced mode
-# Horizontal Sync = 37.9kHz
-# Timing: H=(1.20us, 3.80us, 1.40us) V=(0.13ms, 0.053ms, 0.69ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"800x600"     40      800 848 1000 1056     600  605  607  633
-
-#
-# VESA 800x600@72Hz Non-Interlaced mode
-# Horizontal Sync = 48kHz
-# Timing: H=(1.12us, 2.40us, 1.28us) V=(0.77ms, 0.13ms, 0.48ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"800x600"     50      800  856  976 1040    600  637  643  666  +hsync +vsync
-
-#
-# 1024x768@43.5Hz, Interlaced mode (8514/A standard)
-# Horizontal Sync = 35.5kHz
-# Timing: H=(0.54us, 1.34us, 1.25us) V=(0.23ms, 0.23ms, 0.93ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1024x768i"   44.9   1024 1048 1208 1264    768  776  784  817  Interlace
-
-#
-# VESA 1024x768@60Hz Non-Interlaced mode
-# Horizontal Sync = 48.4kHz
-# Timing: H=(0.12us, 2.22us, 2.58us) V=(0.06ms, 0.12ms, 0.60ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1024x768"    65     1024 1032 1176 1344    768  771  777  806 -hsync -vsync
-
-#
-# 1024x768@60Hz Non-Interlaced mode (non-standard dot-clock)
-# Horizontal Sync = 48.4kHz
-# Timing: H=(0.65us, 2.84us, 0.65us) V=(0.12ms, 0.041ms, 0.66ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1024x768"    62     1024 1064 1240 1280   768  774  776  808
-
-#
-# VESA 1024x768@70Hz Non-Interlaced mode
-# Horizontal Sync=56.5kHz
-# Timing: H=(0.32us, 1.81us, 1.92us) V=(0.05ms, 0.14ms, 0.51ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1024x768"    75     1024 1048 1184 1328    768  771  777  806 -hsync -vsync
-
-#
-# 1024x768@70Hz Non-Interlaced mode (non-standard dot-clock)
-# Horizontal Sync=56.25kHz
-# Timing: H=(0.44us, 1.89us, 1.22us) V=(0.036ms, 0.11ms, 0.53ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1024x768"    72     1024 1056 1192 1280    768  770  776 806   -hsync -vsync
-
-#
-# 1024x768@76Hz Non-Interlaced mode
-# Horizontal Sync=62.5kHz
-# Timing: H=(0.09us, 1.41us, 2.45us) V=(0.09ms, 0.048ms, 0.62ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1024x768"    85     1024 1032 1152 1360    768  784  787  823
-
-#
-# 1280x1024@44Hz, Interlaced mode
-# Horizontal Sync=51kHz
-# Timing: H=(0.02us, 2.7us, 0.70us) V=(0.02ms, 0.24ms, 2.51ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1280x1024i"  80     1280 1296 1512 1568   1024 1025 1037 1165  Interlace
-
-#
-# Alternate 1280x1024@44Hz, Interlaced mode (non-standard dot-clock)
-# Horizontal Sync=47.6kHz
-# Timing: H=(0.42us, 2.88us, 0.64us) V=(0.08ms, 0.12ms, 0.96ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1280x1024i"  75     1280 1312 1528 1576   1024 1028 1034 1080  Interlace
-
-#
-# 1280x1024@59Hz Non-Interlaced mode (non-standard)
-# Horizontal Sync=63.6kHz
-# Timing: H=(0.36us, 1.45us, 2.25us) V=(0.08ms, 0.11ms, 0.65ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1280x1024"  110     1280 1320 1480 1728   1024 1029 1036 1077
-
-#
-# 1280x1024@61Hz, Non-Interlaced mode
-# Horizontal Sync=64.25kHz
-# Timing: H=(0.44us, 1.67us, 1.82us) V=(0.02ms, 0.05ms, 0.41ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1280x1024"  110     1280 1328 1512 1712   1024 1025 1028 1054
-
-#
-# 1280x1024@74Hz, Non-Interlaced mode
-# Horizontal Sync=78.85kHz
-# Timing: H=(0.24us, 1.07us, 1.90us) V=(0.04ms, 0.04ms, 0.43ms)
-#
-# name        clock   horizontal timing     vertical timing      flags
-"1280x1024"  135     1280 1312 1456 1712   1024 1027 1030 1064
 .De
+This section includes a \f(CWDefaultDepth\fP entry for the sake of example.  In
+this case, it's not strictly needed, because there's only one pixel depth.  If
+there were more than one Display subsection, it would tell
+.Command xinit
+which depth to use by default.
 ..endif
-..if finished
-To get out of X windows, type: \f(CWexit\fP in the console xterm.  You can
-customize your X by creating .xinitrc, .xserverrc, and .twmrc files in your home
-directory as described in the xinit and startx man pages.  6.  Rebuilding
-Kernels for X
-
-The GENERIC FreeBSD 2.0 and 2.0.5 kernels support XFree86 without any
-modifications required.  You do not need to make any changes to the
-GENERIC kernel or any kernel configuration which is a superset.
-
-For a general description of BSD kernel configuration get
-smm.02.config.ps.Z
-<ftp://gatekeeper.dec.com/pub/BSD/manuals/smm.02.config.ps.Z>.  It is
-a ready-to-print postscript copy of the kernel configuration chapter
-from the system maintainers manual.
-
-If you do decide to reduce your kernel configuration file, do not
-remove the two lines below (in /sys/arch/i386/conf).  They are both
-required for X support:
-
-
-options                XSERVER                 #Xserver
-options                UCONSOLE                #X Console support
-
-
-
-The generic FreeBSD 2.0 and 2.0.5 kernels are configured by default
-with the syscons driver.  To configure your kernel similarly it should
-have a line like this in /usr/src/sys/i386/conf/GENERIC:
-
-
-device         sc0     at isa? port "IO_KBD" tty irq 1 vector scintr
-
-
-
-The number of virtual consoles can be set using the NCONS option:
-
-
-options                "NCONS=4"               #4 virtual consoles
-
-
-
-Otherwise, the default without a line like this is 12.  You must have
-more VTs than gettys as described in the end of section 3, and 4 is a
-reasonable minimum.
-
-The server supports several console drivers: pccons, syscons and pcvt.
-The syscons driver is the default in FreeBSD 1.1.5 and higher.  They
-are detected at runtime and no configuration of the server itself is
-required.
-
-The pcvt console driver is bundled in /usr/ports/util/pcvt in FreeBSD
-versions 1.0.2 and above.  It can also be ftp-ed from:
-
-FreeBSD.cdrom.com:/pub/FreeBSD/FreeBSD-1.1/ports/util/pcvt
-<ftp://FreeBSD.cdrom.com/pub/FreeBSD/FreeBSD-1.1/ports/util/pcvt>
-
-Refer to the README.FreeBSD
-<ftp://FreeBSD.cdrom.com/pub/FreeBSD/FreeBSD-1.1/ports/util/pcvt/README.FreeBSD>
-file there for complete installation instructions.
-
-The XFree86 servers include support for the MIT-SHM extension.  The
-GENERIC kernel does not support this, so if you want to make use of
-this, you will need a kernel configured with SYSV shared memory
-support.  To do this, add the following line to your kernel config
-file:
-
-
-options                SYSVSHM                 # System V shared memory
-options                SYSVSEM                 # System V semaphores
-options                SYSVMSG                 # System V message queues
-
-
-
-If you are using a SoundBlaster 16 on IRQ 2 (9), then you need a patch
-for sb16_dsp.c.  Otherwise a kernel configured with the SoundBlaster
-driver will claim interrupt 9 doesn't exist and X server will lock up.
-
-S3 boards and serial port COM 4 cannot be installed together on a system because
-the I/O port addresses overlap.
-
-7.  Rebuilding XFree86
-
-The server link kit allows you to build an X server using a minimum
-amount of disk space.  Just unpack it, make the appropriate changes to
-xf86site.def, type ``./mkmf' and ``make'' to link the server.  See
-README.LinkKit <LinkKit.html> for more info.
-
-The source tree takes about 114 MB before compiling and an additional
-100 MB after ``make World''.  You should configure the distribution by
-editing xf86site.def and site.def in xc/config/cf before compiling.
-By default, the config files are set up to build shared libraries.  If
-you are running a version of FreeBSD that doesn't include shared
-library support, add the following line to site.def:
-
-
-#define BuildBsdSharedLibs             NO
-
-
-
-If your system doesn't have support or SYSV shared memory (for
-example, if you don't have the <sys/shm.h> header), you should disable
-the MIT-SHM extension by adding the following line to site.def:
-
-
-#define HasShm                         NO
-
-
-
-To compile the sources on FreeBSD 1.1 and later, edit
-xc/config/cf/FreeBSD.cf to set the OS version parameters correctly,
-and then type:
-
-
-make World
-
-
-
-If you are running an old version of FreeBSD (before 1.1), then type:
-
-
-make World BOOTSTRAPCFLAGS=-D__FreeBSD__
-
-
-
-
-
-
-8.  Building Other X Clients
-
-The easiest way to build a new client (X application) is to use xmkmf
-if an Imakefile is included with it.  Type ``xmkmf -a'' to create the
-Makefiles, then type ``make''.  Whenever you install additional man
-pages you should update whatis.db by running ``makewhatis
-/usr/X11R6/man''.
-
-On FreeBSD 1.0 and earlier systems, to avoid the ``Virtual memory
-exhausted'' message from cc while compiling, increase the data and
-stack size limits (in csh type ``limit datasize 32M'' and ``limit
-stacksize 16M'').  This is not needed on FreeBSD 2.0 and later since
-the defaults are ample.
-
-Note: Starting with XFree86 2.1 and FreeBSD 1.1, the symbol __386BSD__
-no longer gets defined either by the compiler or via the X config
-files for FreeBSD systems.  When porting clients to BSD systems, make
-use of the symbol BSD for code which is truly BSD-specific.  The value
-of the symbol can be used to distinguish different BSD releases.  For
-example, code specific to the Net-2 and later releases can use:
-
-
-#if (BSD >= 199103)
-
-
-To ensure that this symbol is correctly defined, include <sys/param.h>
-in the source that requires it.  Note that the symbol CSRG_BASED is
-defined for *BSD systems in XFree86 3.1.1 and later.  This should be
-used to protect the inclusion of <sys/param.h>.
-
-For code that really is specific to a particular i386 BSD port, use
-__FreeBSD__ for FreeBSD, __NetBSD__ for NetBSD, __386BSD__ for 386BSD,
-and __bsdi__ for BSD/386.
-..endif
-..if article
+.br
+.ne 15v
+.H2 "Multiple monitors and servers"
+.Pn multihead
+.X "X, multiple monitors"
+We've seen above that X provides for more than one monitor per server.  If you
+have multiple display cards and monitors, let the server generate the
+.File XF86Config
+file: it generates a file that supports all identified devices.  The resultant
+server layout section might look like this:
+.Dx
+Section "ServerLayout"
+        Identifier     "XFree86 Configured"
+        Screen      0  "Screen0" 0 0
+        Screen      1  "Screen1" RightOf "Screen0"
+        Screen      2  "Screen2" RightOf "Screen1"
+        InputDevice    "Mouse0" "CorePointer"
+        InputDevice    "Keyboard0" "CoreKeyboard"
+EndSection
+.De
+The file will also have multiple monitor, device and screen sections.  The
+server can't know about the real physical layout of the screen, of course, so
+you may have to change the ordering of the screens.  When you run the server
+without any other specifications, it is assigned server number 0, so these
+screens will be numbered \fI:0.0\fP, \fI:0.1\fP\/ and \fI:0.2\fP.
+.H3 "Multiple servers"
+.X "X, multiple servers"
+It's also possible to run more than one X server on a single system, even if it
+only has a single monitor.  There can be some good reasons for this: you may
+share a system amongst your family members, so each of them can have their own
+server.  Alternatively, you may have a laptop with a high-resolution display and
+need to do a presentation on overhead projectors that can't handle more than
+1024x768 pixels.  It's not practical to simply switch to a lower resolution,
+because the overall screen size doesn't change, and it's difficult to avoid
+sliding the image around when you move the cursor.
+.P
+For each server, you require one virtual terminal\(emsee page
+.Sref \*[xdm] \&
+for more details.  If you're using the same hardware, you can also use the same
+.File XF86Config
+file.  The only difference is in the way in which you start the server.  For
+example, you could start three X servers, one with the \fIfvwm2\fP\/ window
+manager, one with \fIKDE\fP\/ and one with \fIGNOME\fP, with the following
+script:
+.Dx
+xinit &
+xinit .xinitrc-kde -- :1 &
+xinit .xinitrc-gnome -- :2 -xf86config XF86Config.1024x768 &
+.De
+Due to different command line options, you must use
+.Command xinit
+here, and not
+.Command startx .
+The first
+.Command xinit
+starts a server with the default options:  it reads its commands from
+.File .xinitrc ,
+it has the server number 0, and it reads its configuration from the default
+.File XF86Config
+file.
+The second server reads its commands from
+.File .xinitrc-kde ,
+it has the server number 1, and it reads its configuration from the default
+.File XF86Config
+file.
+The third server reads its commands from
+.File .xinitrc-gnome ,
+it has the server number 2, and the configuration file is
+.File XF86Config.1024x768 .
+Assuming that you reserve virtual terminals
+.Device -n ttyv7 ,
+.Device -n ttyv8
+and
+.Device -n ttyv9
+for the servers, you can switch between them with the key combinations
+\fBCtrl-Alt-F8\fP,  \fBCtrl-Alt-F9\fP and  \fBCtrl-Alt-F10\fP.
+.H2 "X in the network"
+.Pn network-X
+.X "X, networking"
+X is a network protocol.  So far we have looked at the server.  The clients are
+the individual programs, such as
+.Command xterm ,
+.Command emacs
+or a web browser, and they don't have to be on the same machine.  A special
+notation exists to address X servers and screens:
+.Ds
+\fISystem name\fP\/\f(CB:\fP\fIserver number\fP\/\f(CB.\fP\fIscreen number\fP\/
+.De
+When looking at X client-server interaction, remember that the server is the
+software component that manages the display.  This means that you're always
+sitting at the server, not at the client.  For example, if you want to start an
+.Command xterm
+client on \fIfreebie\fP\/ and display it on \fIpresto\fP, you'll be sitting at
+\fIpresto\fP.  To do this, you could type in, on \fIpresto\fP,
+.Dx
+$ \f(CBssh freebie xterm -ls -display presto:0 &\fP
+.De
+.X "~/.rhosts"
+The flag \f(CW-ls\fP tells
+.Command xterm
+that this is a \fIlogin shell\fP, which causes it to read in the startup files.
 .P
-.\".1C 1
-\fIGreg Lehey is an independent computer consultant specializing in UNIX.  Born
-in Australia, he was educated in Malaysia and England before studying Chemistry
-in Germany and Chemical Engineering in England.  He has spent his professional
-career in Germany, where he worked for computer manufacturers such as Univac,
-Tandem, and Siemens-Nixdorf, the German space research agency, nameless software
-houses and a large user before deciding to work for himself.  In the course of
-over 20 years in the industry he has performed most jobs, ranging from kernel
-development to product marketing, systems programming to operating, processing
-satellite data to programming gasoline pumps.  About the only thing he hasn't
-done is writing commercial applications software.  He is currently engaged in
-the production of CD-ROMs of ported free software, and this book is one result
-of his experience in this area.  He is available for short-term contracts and
-can be reached by mail at \f(CWgrog@FreeBSD.ORG\fP or \f(CWgrog@lemis.de\fP.
-.P
-When he can drag himself away from his basement full of UNIX workstations, he is
-involved in performing baroque and classical woodwind music on his collection of
-original instruments, exploring the German countryside with his family on their
-Arab and Peruvian horses, or exploring new cookery techniques or ancient and
-obscure European languages.
-..endif
+For this to work, you must tell the X server to allow the connection.  There are
+two things to do:
+.Ls B
+.LI
+Use
+.Command xhost
+to specify the names of the systems that have access:
+.Dx
+$ \f(CBxhost freebie presto bumble wait gw\fP
+.De
+This enables access from all the systems on our reference network, including the
+one on which it is run.  You don't need to include your own system, which is
+enabled by default, but if you do, you can use the same script on all systems on
+the network.
+.LI
+.Command xhost
+is not a very robust system, so by default
+.Command startx
+starts X with the option \f(CW-nolisten tcp\fP.  This completely blocks access
+from other systems.  If you want to allow remote clients to access your X
+server, modify
+.X "startx, command"
+.X "command, startx"
+.Command -n /usr/X11R6/bin/startx ,
+which contains the text:
+.Dx
+listen_tcp="-nolisten tcp"
+.De
+Change this line to read:
+.Dx
+listen_tcp=
+.De
+This enables remote connections the next time you start the server.
+.Le
+.ne 15v
+.H3 "Multiple monitors across multiple servers"
+.X "X, multiple monitors"
+.X "X, multiple servers"
+We saw above that a server can handle multiple monitors, and a system can handle
+multiple servers.  One problem with multiple monitors is that most computers can
+only handle a small number of display boards: a single AGP board and possibly a
+number of PCI boards.  But PCI boards are difficult to find nowadays, and
+they're slower and have less memory.
+.P
+If you have a number of machines located physically next to each other, you have
+the alternative of running X on each of them and controlling everything from one
+keyboard and mouse.  You do this with the
+.Daemon x11/x2x
+port.  For example: \fIfreebie\fP, \fIpresto\fP\/ and \fIbumble\fP\/ have
+monitors next to each other, and \fIpresto\fP\/ has two monitors.  From left to
+right they are \fIfreebie:0.0\fP, \fIpresto:0.0\fP, \fIpresto:0.1\fP\/ and
+\fIbumble:0.0\fP.  The keyboard and mouse are connected to \fIpresto\fP.  To
+incorporate \fIfreebie:0.0\fP\/ and \fIbumble:0.0\fP\/ in the group, enter these
+commands on \fIpresto\fP\/:
+.Dx
+$ \f(CBDISPLAY=:0.0 x2x -west -to freebie:0 &\fP
+$ \f(CBDISPLAY=:0.1 x2x -east -to bumble:0 &\fP
+.De
+After this, you can move to the other machines by moving the mouse in the
+corresponding direction.  It's not possible to continue to a further machine,
+but it is possible to connect in other directions (\fInorth\fP\/ and
+\fIsouth\fP\/) from each monitor on \fIpresto\fP, which in this case would allow
+connections to at least six other machines.  Before that limitation becomes a
+problem, you need to find space for all the monitors.
+.H3 "Stopping X"
+.X "X, stopping"
+To stop X, press the key combination \fBCtrl\fP-\fBAlt\fP-\fBBackspace\fP, which
+is deliberately chosen to resemble the key combination
+\fBCtrl\fP-\fBAlt\fP-\fBDelete\fP used to reboot the machine.
+\fBCtrl\fP-\fBAlt\fP-\fBBackspace\fP stops X and returns you to the virtual
+terminal in which you started it.  If you run from
+.Daemon xdm ,
+it redisplays a login screen.
