Import of XFree86 3.9.17

20 files changed, 1543 insertions, 874 deletions

diff --git a/xc/programs/Xserver/hw/xfree86/doc/DESIGN b/xc/programs/Xserver/hw/xfree86/doc/DESIGN
index 8b09203f0..edf491ee6 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/DESIGN
+++ b/xc/programs/Xserver/hw/xfree86/doc/DESIGN
@@ -2,7 +2,7 @@
 
                           The XFree86 Project, Inc
 
-                         Last modified 17 July 1999
+                       Last modified 25 November 1999
 
 NOTE: This is a DRAFT document, and the interfaces described here are subject
 to change without notice.
@@ -122,11 +122,14 @@ possible to override the global values in the ServerFlags section.
 A ServerLayout section can be made active by being referenced on the command
 line.  In the absence of this, a default will be chosen (the first one
 found).  The screen names may optionally be followed by a number specifying
-the preferred screen number, and optionally by the names of the four screens
-adjacent to it.  The order of these is top, bottom, left, right.  When no
-screen number is specified, they are numbered according to the order in which
-they are listed.  Here is an example of a ServerLayout section for two
-screens, with the second located to the right of the first:
+the preferred screen number, and optionally by information specifying the
+physical positioning of the screen, either in absolute terms or relative to
+another screen (or screens).  When no screen number is specified, they are
+numbered according to the order in which they are listed.  The old (now obso-
+lete) method of providing the positioning information is to give the names of
+the four adjacent screens.  The order of these is top, bottom, left, right.
+Here is an example of a ServerLayout section for two screens using the old
+method, with the second located to the right of the first:
 
            Section "ServerLayout"
              Identifier "Main Layout"
@@ -135,6 +138,44 @@ screens, with the second located to the right of the first:
              Screen     "Screen 3"
            EndSection
 
+The preferred way of specifying the layout is to explicitly specify the
+screen's location in absolute terms or relative to another screen.
+
+In the absolute case, the upper left corner's coordinates are given after the
+Absolute keyword.  If the coordinates are omitted, a value of (0,0) is
+assumed.  An example of absolute positioning follows:
+
+           Section "ServerLayout"
+             Identifier "Main Layout"
+             Screen     "Screen 1" 0 Absolute 0 0
+             Screen     "Screen 2" 1 Absolute 1024 0
+             Screen     "Screen 3" Absolute 2048 0
+           EndSection
+
+In the relative case, the position is specified by either using one of the
+following keywords followed by the name of the reference screen:
+
+     RightOf
+
+     LeftOf
+
+     Above
+
+     Below
+
+     Relative
+
+When the Relative keyword is used, the reference screen name is followed by
+the coordinates of the new screen's origin relative to reference screen.  The
+following example shows how to use some of the relative positioning options.
+
+           Section "ServerLayout"
+             Identifier "Main Layout"
+             Screen     "Screen 1" 0
+             Screen     "Screen 2" 1 RightOf "Screen 1"
+             Screen     "Screen 3" Relative "Screen 1" 2048 0
+           EndSection
+
 2.5  Options
 
 Options are used more extensively.  They may appear in most sections now.
@@ -755,7 +796,7 @@ bit order, bitmap scanline unit and image byte order are compared for each of
 the screens.  If a mismatch is found, the server exits with an appropriate
 message.
 
-5.15  Check of Resource Control is Needed
+5.15  Check if Resource Control is Needed
 
 Determine if resource access control is needed.  This is the case if more
 than one screen is used.  If necessary the RAC wrapper module is loaded.
@@ -909,19 +950,40 @@ does the following:
 
      Bool ChipEnterVT(int index, int flags)
 
-          This function should map memory regions, initialise the
-          current video mode and initialise the viewport, turn on
-          the HW cursor if appropriate, etc.
+          This function should initialise the current video mode
+          and initialise the viewport, turn on the HW cursor if
+          appropriate, etc.
 
           Should it re-save the video state before initialising the
           video mode?
 
      void ChipLeaveVT(int index, int flags)
 
-          This function should restore the saved video state and
-          unmap the memory regions.  If appropriate it should also
-          turn off the HW cursor, and invalidate any pixmap/font
-          caches.
+          This function should restore the saved video state.  If
+          appropriate it should also turn off the HW cursor, and
+          invalidate any pixmap/font caches.
+
+     Optionally, ChipLeaveVT() may also unmap memory regions.  If so,
+     ChipEnterVT() will need to remap them.  Additionally, if an aper-
+     ture used to access video memory is unmapped and remapped in this
+     fashion, ChipEnterVT() will also need to notify the framebuffer
+     layers of the aperture's new location in virtual memory.  This is
+     done with a call to the screen's ModifyPixmapHeader() function, as
+     follows
+
+          (*pScreen->ModifyPixmapHeader)(pScrn->ppix,
+
+                    -1, -1, -1, -1, -1, NewApertureAddress);
+
+               where the ``ppix'' field in a ScrnInfoRec
+               points to the pixmap used by the screen's
+               SaveRestoreImage() function to hold the
+               screen's contents while switched out.
+
+     Currently, aperture remapping, as described here, should not be
+     attempted if the driver uses the xf8_16bpp or xf8_32bpp framebuffer
+     layers.  A pending restructuring of VT switching will address this
+     restriction in the near future.
 
 Other layers may wrap the ChipEnterVT() and ChipLeaveVT() functions if they
 need to take some action when these events are received.
@@ -968,6 +1030,25 @@ constraints:
           Check the passed mode for hw-specific constraints, and
           return the appropriate status value.
 
+This function may also modify the effective timings and clock of the passed
+mode.  These have been stored in the mode's Crtc* and SynthClock elements,
+and have already been adjusted for interlacing, doublescanning, multiscanning
+and clock multipliers and dividers.  The function should not modify any other
+mode field, unless it wants to modify the mode timings reported to the user
+by xf86PrintModes().
+
+The function is called once for every mode in the XF86Config Monitor section
+assigned to the screen, with flags set to MODECHECK_INITIAL.  It is subse-
+quently called for every mode in the XF86Config Display subsection assigned
+to the screen, with flags set to MODECHECK_FINAL.  In the second case, the
+mode will have successfully passed all other tests.  In addition, the ScrnIn-
+foRec's virtualX, virtualY and displayWidth fields will have been set as if
+the mode to be validated were to be the last mode accepted.
+
+In effect, calls with MODECHECK_INITIAL are intended for checks that do not
+depend on any mode other than the one being validated, while calls with MOD-
+ECHECK_FINAL are intended for checks that may involve more than one mode.
+
 6.2  Free screen data
 
 When a screen is deleted prior to the completion of the ScreenInit phase the
@@ -2393,7 +2474,16 @@ use the colormap layer, a driver calls the xf86HandleColormaps() function.
                is resetting the hardware during mode switches
                and corrupting or erasing the hardware palette.
 
-          The colormap layer always reloads the palette after VT
+          CMAP_LOAD_EVEN_IF_OFFSCREEN
+
+               reload the colormap even if the screen is
+               switched out of the server's VC.  The palette
+               is not reloaded when the screen is switched
+               back in, nor after mode switches.  This is use-
+               ful when the driver needs to keep track of
+               palette changes.
+
+          The colormap layer normally reloads the palette after VT
           enters so it is not necessary for the driver to save and
           restore the palette when switching VTs.  The driver must,
           however, still save the initial palette during server
@@ -2837,6 +2927,15 @@ The XF86VideoAdaptorRec:
                of the [root] window, if the administrator has
                no hesitations regarding security.
 
+          VIDEO_OVERLAID_STILLS
+
+               Implementing PutStill for hardware that does
+               video as an overlay can be awkward since it's
+               unclear how long to leave the video up for.
+               When this flag is set, StopVideo will be called
+               whenever the destination gets clipped or moved
+               so that the still can be left up until then.
+
      name
 
           The name of the adaptor.
@@ -3762,10 +3861,9 @@ improve the consistency of driver behaviour.
 
 18.2  Functions for setting values based on command line and config file
 
-     Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp, int
-     fbbpp,
+     Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp,
 
-               int depth24flags)
+               int fbbpp, int depth24flags)
 
           This function sets the depth, pixmapBPP and bitsPerPixel
           fields of the ScrnInfoRec.  It also determines the
@@ -4094,37 +4192,51 @@ the helpers.
 
                     first usable mode in list
 
+               The following options can also be combined
+               (OR'ed) with one of the above:
+
                LOOKUP_CLKDIV2
 
                     Allow halved clocks
 
-               LOOKUP_CLKDIV2 can be combined (OR'ed) with one
-               of the others.
+               LOOKUP_OPTIONAL_TOLERANCES
+
+                    Allow missing horizontal sync and/or
+                    vertical refresh ranges in the
+                    XF86Config Monitor section
+
+               LOOKUP_OPTIONAL_TOLERANCES should only be spec-
+               ified when the driver can ensure all modes it
+               generates can sync on, or at least not damage,
+               the monitor or digital flat panel.  Horizontal
+               sync and/or vertical refresh ranges specified
+               by the user will still be honoured (and acted
+               upon).
 
           This function requires that the following fields of the
           ScrnInfoRec are initialised prior to calling it:
 
           clock[]
 
-               List of discrete clocks (when non-pro-
-               grammable).
+               List of discrete clocks (when non-programmable)
 
           numClocks
 
                Number of discrete clocks (when non-pro-
-               grammable).
+               grammable)
 
           progClock
 
-               Whether the clock is programmable or not.
+               Whether the clock is programmable or not
 
-          formats
+          monitor
 
-               pixmap formats for screen
+               Pointer to the applicable XF86Config monitor
+               section
 
-          numFormats
+          fdFormat
 
-               number of pixmap formats for screen
+               Format of the screen buffer
 
           videoRam
 
@@ -4138,6 +4250,11 @@ the helpers.
 
                Maximum vertical timing value allowed
 
+          xInc
+
+               Horizontal timing increment in pixels (defaults
+               to 8)
+
           This function fills in the following ScrnInfoRec fields:
 
           modePool
@@ -4179,14 +4296,22 @@ the helpers.
           limits, and also the virtual width and height limits (if
           greater than zero).  For each mode removed an informa-
           tional message is printed at verbosity level 2.  If the
-          mode pool ends up being empty, an error message is
-          printed, and the return value is -1.
-
-          The final stage is to lookup each mode, and fill in the
-          remaining parameters.  If an error condition is encoun-
-          tered, a message is printed, and the return value is -1.
-          Otherwise, the return value is the number of valid modes
-          found (0 if none are found).
+          mode pool ends up being empty, a warning message is
+          printed, and the return value is 0.
+
+          The final stage is to lookup each mode name, and fill in
+          the remaining parameters.  If an error condition is
+          encountered, a message is printed, and the return value
+          is -1.  Otherwise, the return value is the number of
+          valid modes found (0 if none are found).
+
+          Even if the supplied mode names include duplicates, no
+          two names will ever match the same mode.  Furthermore, if
+          the supplied mode names do not yield a valid mode
+          (including the case where no names are passed at all),
+          the function will continue looking through the mode pool
+          until it finds a mode that survives all checks, or until
+          the mode pool is exhausted.
 
           A message is only printed by this function when a funda-
           mental problem is found.  It is intended that this func-
@@ -4225,7 +4350,8 @@ the helpers.
 
           doubleScanAllowed
 
-               TRUE if doublescan is allowed for this range
+               TRUE if doublescan or multiscan is allowed for
+               this range
 
           ClockMulFactor
 
@@ -4299,10 +4425,6 @@ the helpers.
           This function is normally called after calling
           xf86PruneDriverModes().
 
-          NOTE: The Crtc* fields are not initialised anywhere else,
-          so the driver must either call this function or ini-
-          tialise them itself.
-
      void xf86PrintModes(ScrnInfoPtr scrp)
 
           This function prints out the virtual size setting, and
@@ -4361,7 +4483,9 @@ helper functions.
 
      ModeStatus xf86InitialCheckModeForDriver(ScrnInfoPtr scrp,
 
-               DisplayModePtr mode, int maxPitch,
+               DisplayModePtr mode, ClockRangePtr clockRanges,
+
+               LookupModeFlags strategy, int maxPitch,
 
                int virtualX, int virtualY)
 
@@ -4370,8 +4494,10 @@ helper functions.
           itly, the maxHValue and maxVValue fields of the ScrnIn-
           foRec are also used.  If the ValidMode field of the Scrn-
           InfoRec is set, that function is also called to check the
-          mode.
-          If the mode is consistent with the constraints, the
+          mode.  Next, the mode is checked against the monitor's
+          constraints.
+
+          If the mode is consistent with all constraints, the
           return value is MODE_OK.  Otherwise the return value
           indicates which constraint wasn't met.
 
@@ -5912,7 +6038,7 @@ eScreen() function.
          ZZZFreeRec(xf86Screens[scrnIndex]);
      }
 
-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.9 1999/07/18 03:26:51 dawes Exp $
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.16 1999/11/26 00:31:12 dawes Exp $
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/DESIGN,v 1.5 1999/07/18 08:34:28 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/DESIGN,v 1.13 1999/11/26 00:58:20 dawes Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/Monitors b/xc/programs/Xserver/hw/xfree86/doc/Monitors
index 19e084e7a..88712007f 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/Monitors
+++ b/xc/programs/Xserver/hw/xfree86/doc/Monitors
@@ -1324,7 +1324,7 @@ Section "Monitor"
     VertRefresh 50-130
 EndSection
 
-#From: andrew.van.der.stock@member.sage-au.org.au (Andrew van der Stock)
+#From: ajv@greebo.net (Andrew van der Stock)
 #Date: 21 May 1997, 22:00:00 AEST
 
 Section "Monitor"
@@ -1382,5 +1382,5 @@ Section "Monitor"
 EndSection
 
 
-# $XFree86: xc/programs/Xserver/hw/xfree86/doc/Monitors,v 3.17 1997/07/31 10:30:12 hohndel Exp $
+# $XFree86: xc/programs/Xserver/hw/xfree86/doc/Monitors,v 3.18 1999/11/19 13:54:25 hohndel Exp $
 # $XConsortium: Monitors /main/13 1996/10/25 14:11:55 kaleb $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.MGA b/xc/programs/Xserver/hw/xfree86/doc/README.MGA
index 2b98be35c..e274cc161 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/README.MGA
+++ b/xc/programs/Xserver/hw/xfree86/doc/README.MGA
@@ -170,7 +170,7 @@ Mark Vojkovich, mvojkovi@sdcc10.ucsd.edu
 
 and:
 
-   o Andrew Vanderstock, vanderaj@mail2.svhm.org.au
+   o Andrew van der Stock, ajv@greebo.net
 
    o Angsar Hockmann, Ansgar.Hockmann@hrz.uni-dortmund.de
 
@@ -192,7 +192,7 @@ and:
 
    o Doug Merritt, doug@netcom.com
 
-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml,v 3.8 1999/08/23 06:38:47 dawes Exp $
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml,v 3.9 1999/11/19 13:54:27 hohndel Exp $
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.MGA,v 3.11 1999/08/23 07:03:43 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.MGA,v 3.12 1999/11/26 00:58:22 dawes Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD b/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD
index 1e8cf6280..e352d6174 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD
+++ b/xc/programs/Xserver/hw/xfree86/doc/README.NetBSD
@@ -1,12 +1,12 @@
-                        README for XFree86 on NetBSD
+                     README for XFree86 3.9.16 on NetBSD
 
 Rich  Murphey, David Dawes, Marc  Wandschneider, Mark  Weaver, Matthieu Herrb
 
-                       Last modified on: 25 June 1999
+                     Last modified on: 13 November 1999
 
 1.  What and Where is XFree86?
 
-XFree86 is a port of X11R6.3 that supports several versions of Intel-based
+XFree86 is a port of X11R6.4 that supports several versions of Intel-based
 Unix.  It is derived from X386 1.2, which was the X server distributed with
 X11R5.  This release consists of many new features and performance improve-
 ments as well as many bug fixes.  The release is available as source patches
@@ -19,27 +19,11 @@ The sources for XFree86 are available by anonymous ftp from:
 
 ftp://ftp.XFree86.org/pub/XFree86/current
 
-Binaries for NetBSD 1.2 are available from:
-ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.2
-
-Binaries for NetBSD 1.4 and later are available from:
-ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.4
-
 A list of mirror sites is provided by ftp://ftp.XFree86.org/pub/XFree86/MIR-
 RORS
 
-Other NetBSD versions:
-
-These binaries are not compatible with earlier NetBSD versions. If you're
-still running NetBSD 0.9, 1.0 or 1.1, you should think about upgrading to a
-newer version of NetBSD first.
-
-If you don't upgrade, you'll have to build XFree86 from the sources.  XFree86
-should compile cleanly under earlier versions of NetBSD, although this has
-not been tested.
-
 XFree86 also builds on NetBSD/sparc. See section Building on other architec-
-tures (section 8.5, page 1) for details.
+tures (section 8.3, page 1) for details.
 
 The client side of XFree86 also builds on NetBSD/alpha and many other archi-
 tecture supported by NetBSD.
@@ -48,18 +32,17 @@ XFree86 also supports NetBSD on PC98 machines.
 
 2.  Bug Reports for This Document
 
-Send email to matthieu@laas.fr (Matthieu Herrb) or XFree86@XFree86.org if you
-have comments or suggestions about this file and we'll revise it.
+Send email to herrb@XFree86.Org (Matthieu Herrb) or XFree86@XFree86.org if
+you have comments or suggestions about this file and we'll revise it.
 
 3.  New features in this release
 
-   o The maximum number of open connections in the server has been raised to
-     128,
+   o Support for silken mouse with the wsmouse protocol has been added.
 
-   o support for the wsmouse mouse protocol included in  NetBSD 1.4 has been
-     added.
+   o A new version of the XFree86 Aperture driver which provides MTRR support
+     is included.
 
-See the Release Notes for non-OS dependent new features in XFree86 3.3.4.
+See the Release Notes for non-OS dependent new features in XFree86 3.9.17.
 
 4.  Installing the Binaries
 
@@ -72,9 +55,6 @@ The /etc/XF86Config file tells the X server what kind of monitor, video card
 and mouse you have.  You must create it to tell the server what specific
 hardware you have.
 
-The easiest way to create this file is to run the XF86Setup utility as root.
-Refer to QuickStart.doc for details about its use.
-
 You'll need info on your hardware:
 
    o Your mouse type, baud rate and its /dev entry.
@@ -107,59 +87,15 @@ Only standard PS/2 mice are supported by this driver. Newest PS/2 mice that
 send more than three bytes at a time (especially Intellimouse, or MouseMan+
 with a ``3D'' roller) are not supported yet.
 
-XFree86 3.3.4 also has support for the mouse driver included in the new
+XFree86 3.9.17 also has support for the mouse driver included in the new
 wscons console driver introduced by NetBSD 1.4. Specify ``wsmouse'' as the
 protocol and ``/dev/wsmouse0'' as the device in /etc/XF86Config if you're
 using NetBSD 1.4 with wscons.
 
 See README.mouse  for general instruction on mouse configuration in XFree86.
 
-5.2  Other input devices
-
-XFree86  supports the dynamic loading of drivers for external input devices
-using the XInput extension. Currently supported devices are:
-
-   o Joystick (xf86Jstk.so)
-
-   o Wacom tablets (Wacom IV protocol only, xf86Wacom.so)
-
-   o SummaSketch tablets (xf86Summa.so)
-
-   o Elographics touchscreen (xf86Elo.so)
-
-To use a specific device, add the line
-
-     load "module"
-
-in the Module section of XF86Config, where module is the name of the .so file
-corresponding to your device.  You also need to set up a XInput section in
-XF86Config.  Refer to the XF86Config(5) man page for detailed configuration
-instructions.
-
-You can then change the device used to drive the X pointer with the xset-
-pointer(1) command.
-
-For joystick support, you'll need to install the joystick device driver in
-the kernel. It is included in NetBSD 1.2. See joy(4) for details.
-
-5.3  Configuring PEX and XIE extensions
-
-The PEX and XIE extensions are  supported as external modules.  If you want
-to have access to these extensions, add the following lines to the Module
-section of XF86Config:
-
-        load    "pex5.so"
-        load    "xie.so"
-
 6.  Running X
 
-8mb of memory is a recommended minimum for running X.  The server, window
-manager and an xterm take about 4 Mb of memory themselves.  On a 4Mb system
-that would leave nothing left over for other applications like gcc that
-expect a few meg free.  X will work with 4Mb of memory, but in practice com-
-pilation while running X can take 5 or 10 times as long due to constant pag-
-ing.
-
 The easiest way for new users to start X windows is to type:
 
      startx >& startx.log
@@ -256,59 +192,47 @@ wscons into the kernel.
 
 7.2  Aperture Driver
 
-By default NetBSD 0.9C and higher include the BSD 4.4 kernel security feature
-that disable access to the /dev/mem device when in multi-users mode. But
-XFree86 servers can take advantage (or require) linear access to the display
-memory.
+By default NetBSD include the BSD 4.4 kernel security feature that disable
+access to the /dev/mem device when in multi-users mode. But XFree86 servers
+can take advantage (or require) linear access to the display memory.
 
-Moset recent accelerated servers require linear memory access, some other can
+Most recent accelerated servers require linear memory access, some other can
 take advantage of it, but do not require it.
 
 There are two ways to allow XFree86 to access linear memory:
 
-The first way is to disable the kernel security feature by adding `option
-INSECURE' in the kernel configuration file and build a new kernel.
-
-The second way is to install the aperture driver: You can get the aperture
-driver sources from ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/apNetBSD.shar.
-
-How to activate it is highly dependent from your exact operating system ver-
-sion:
-
-   o  NetBSD 1.0, 1.1, 1.2, 1.2.1:
+The first way is to disable the kernel security feature by adding ``option
+INSECURE'' in the kernel configuration file and build a new kernel.
 
-     Add the following lines to the end of /etc/rc.local:
+The second way is to install the aperture driver, included in source form in
+xc/programs/Xserver/hw/xfree86/etc/apNetBSD-2.shar in the XFree86 3.9.17
+source distribution. Unpack it in a new directory of your choice by running:
 
-           KERNDIR=/usr/X11R6/lib/X11/kernel
-           if [ -f ${KERNDIR}/ap.o ]; then
-             modload -o ${KERNDIR}/ap -e ap -p ${KERNDIR}/apinstall ${KERNDIR}/ap.o
-           fi
+       sh apNetBSD-2.shar
 
-   o  NetBSD 1.2D and later
+Then run ``make build'' as root to install it. To enable it, add the follow-
+ing line to  /etc/lkm.conf:
 
-     Add the following line to  /etc/lkm.conf:
+     /usr/X11R6/lib/X11/kernel/ap.o  -  - /usr/X11R6/lib/X11/kernel/apinstall - -
 
-          /usr/X11R6/lib/X11/kernel/ap.o  -  ap /usr/X11R6/lib/X11/kernel/apinstall -
-
-   o  NetBSD 1.2G, 1.3 and later
-
-     The lkm.conf format changed in 1.2G.  Add the following line to
-     /etc/lkm.conf:
-
-          /usr/X11R6/lib/X11/kernel/ap.o  -  ap /usr/X11R6/lib/X11/kernel/apinstall - -AFTERMOUNT
+and set ``lkm=YES'' in /etc/rc.conf
 
 Reboot your system. XFree86 will auto-detect the aperture driver if avail-
 able.
 
-Warning: if you boot another kernel than /netbsd or /bsd, loadable kernel
-modules can crash your system. Always boot in single user mode when you want
-to run another kernel.
+Warning 1: if you boot another kernel than /netbsd, loadable kernel modules
+can crash your system. Always boot in single user mode when you want to run
+another kernel.
 
-     Caveat: the  aperture driver only allows one access at a time (so
-     that the system is in the same security state once X is launched).
-     This means that if you run multiple servers on multiples VT, only
-     the first one will have linear memory access.  Use 'option INSE-
-     CURE' if you need more that one X server at a time.
+Warning 2: the  aperture driver only allows one access at a time (so that the
+system is in the same security state once X is launched). This means that if
+you run multiple servers on multiples VT, only the first one will have linear
+memory access.  Use ``option INSECURE'' if you need more that one X server at
+a time.
+
+Together with XFree86 3.9.17, a new version of the aperture driver is pro-
+vided, which also supports MTRR write combining on Pentiums II and AMD K6
+class processors.
 
 7.3  MIT-SHM
 
@@ -326,11 +250,6 @@ to your kernel config file.
 
 8.  Rebuilding the XFree86 Distribution
 
-The server link kit allow you to rebuild just the X server with a minimum
-amount of disk space.  Just unpack it, make the appropriate changes to the
-xf86site.def, type ``./mkmf'' and ``make'' to link the server.  See
-/usr/X11R6/lib/Server/README for more info.
-
 See INSTALL for instructions on unbundling and building the source distribu-
 tion.
 
@@ -338,6 +257,10 @@ You should configure the distribution by editing xc/config/cf/host.def
 before compiling.  To compile the sources, invoke ``make World'' in the xc
 directory.
 
+To build the XFree86 server with the Aperture driver enabled, you should
+unpack apNetBSD-2.shar and install it before making World in the XFree86
+tree.
+
 8.1  Console drivers
 
 XFree86 has a configuration option to select the console drivers to use in
@@ -351,21 +274,9 @@ xf86site.def:
 
            #define XFree86ConsoleDefines -DPCVT_SUPPORT
 
-   o if you're using syscons put:
-
-           #define XFree86ConsoleDefines -DSYSCONS_SUPPORT
-
-   o if you're running codrv put:
-
-           #define XFree86ConsoleDefines -DCODRV_SUPPORT
-
 If you don't define XFree86ConsoleDefines in xf86site.def the pccons and pcvt
 drivers will be supported by default.
 
-Syscons and codrv are not bundled with NetBSD. They are available by anony-
-mous FTP from a number of sites. They are not supported by the XFree86 binary
-distribution anymore.
-
 8.2  pcvt_ioctl.h file:
 
 XFree86's default configuration includes support for the PCVT console driver.
@@ -379,30 +290,7 @@ If you don't have kernel sources, you can grab this file from ftp.netbsd.org
 or one of its mirrors. If you're not running PCVT, you can remove -DPCVT_SUP-
 PORT from XFree86ConsoleDefines in xf86site.def too.
 
-8.3  console.h and ioctl_pc.h files:
-
-If you want to build a server supporting codrv and you don't already have the
-corresponding header file ioctl_pc.h installed in /usr/include/machine, then
-install the copy that is supplied in xc/programs/Xserver/hw/xfree86/etc.  If
-you run NetBSD-current you probably want to install it in
-/usr/src/sys/arch/i386/include too, so that it get reinstalled each time you
-run make includes.
-
-If you have installed the  codrv console driver, this file should be taken
-from your installed version of the driver.
-
-The console.h file for syscons isn't distributed with XFree86 anymore. You
-should get it from the syscons distribution.
-
-8.4  Support for shared libs under NetBSD 1.0 and later
-
-By default XFree86 builds for NetBSD with shared libraries support. If you're
-building on 0.9 or don't want shared libraries add the following line to
-host.def:
-
-     #define BuildBsdSharedLibs    NO
-
-8.5  Building on other architectures
+8.3  Building on other architectures
 
 XFree86 also compiles on NetBSD/sparc. The Sun server patches from Dennis
 Ferguson and Matthew Green have been integrated in xc/pro-
@@ -418,7 +306,7 @@ grams/Xserver/hw/sun.  Small modifications to xf86site.def are needed:
    o Look at other applicable options in the INSTALL document.
 
 Problems with this port should be reported to the port-sparc@NetBSD.Org mail-
-ing list or directly to me matthieu@laas.fr rather than to the xfree86 mail-
+ing list or directly to me herrb@XFree86.Org rather than to the xfree86 mail-
 ing list.
 
 Note that the NetBSD project has now its own source tree, based on the
@@ -438,12 +326,10 @@ 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'').
 
-Note: Starting with XFree86 2.1 and NetBSD 0.9A, the symbol __386BSD__ no
-longer gets defined either by the compiler or via the X config files for *BSD
-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:
+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 distin-
+guish different BSD releases.  For example, code specific to the Net-2 and
+later releases can use:
 
      #if (BSD >= 199103)
 
@@ -453,8 +339,8 @@ 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, __OpenBSD__ for OpenBSD,
-__386BSD__ for 386BSD, and __bsdi__ for BSD/386.
+__FreeBSD__ for FreeBSD, __NetBSD__ for NetBSD, __OpenBSD__ for OpenBSD, and
+__bsdi__ for BSD/386.
 
 Another note: If you get the message:
 
@@ -468,22 +354,13 @@ your library list in the Imakefile or Makefile and relink.
 
 10.  Thanks
 
-Many thanks to:
-
-   o Pace Willison for providing the initial port to 386BSD.
-
-   o Amancio Hasty for fixing cursor restoration, mouse bugs and many others.
-
-   o Christoph Robitschko for fixing com.c and thus select().
-
-   o Nate Williams for the patchkit support for X.
-
-   o Rod Grimes and Jack Velte of Walnut Creek Cdrom for use of their
-     machines in preparing the FreeBSD binary release.
+Many thanks to all people who contributed to make XFree86 work on *BSD, in
+particular, David Dawes, Pace Willison, Amancio Hasty, Christoph Robitschko,
+Nate Williams, Rod Grimes, Jack Velte and Michael Smith.
 
-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.49 1999/08/23 06:38:48 dawes Exp $
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.51 1999/11/26 00:51:51 dawes Exp $
 
      $XConsortium: NetBSD.sgml /main/26 1996/10/28 05:43:20 kaleb $
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.NetBSD,v 3.63 1999/08/23 07:03:44 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.NetBSD,v 3.64 1999/11/26 00:58:22 dawes Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD b/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD
index f3c6dfa85..7f872f336 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD
+++ b/xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD
@@ -1,12 +1,12 @@
-                        README for XFree86 on OpenBSD
+                    README for XFree86 3.9.16 on OpenBSD
 
                                Matthieu Herrb
 
-                       Last modified on: 25 June 1999
+                     Last modified on: 13 November 1999
 
 1.  What and Where is XFree86?
 
-XFree86 is a port of X11R6.3 that supports several versions of Intel-based
+XFree86 is a port of X11R6.4 that supports several versions of Intel-based
 Unix.  It is derived from X386 1.2, which was the X server distributed with
 X11R5.  This release consists of many new features and performance improve-
 ments as well as many bug fixes.  The release is available as source patches
@@ -19,15 +19,11 @@ The sources for XFree86 are available by anonymous ftp from:
 
 ftp://ftp.XFree86.org/pub/XFree86/current
 
-Binaries for OpenBSD 2.5 and later are available from:
-
-ftp://ftp.XFree86.org/pub/XFree86/current/binaries/OpenBSD
-
 A list of mirror sites is provided by ftp://ftp.XFree86.org/pub/XFree86/MIR-
 RORS
 
 XFree86 also builds on other OpenBSD architectures. See section Building on
-other architectures (section 8.2, page 1) for details.
+other architectures (section 7.2, page 1) for details.
 
 2.  Bug Reports for This Document
 
@@ -36,27 +32,19 @@ have comments or suggestions about this file and we'll revise it.
 
 3.  New features in this release
 
-   o The maximum number of open connections in the server has been raised to
-     128,
-
-   o the resize utility was fixed.
-
-See the Release Notes for non-OS dependent new features in XFree86 3.3.4.
+   o Silken mouse is supported for serial mices, and, under post 2.6 OpenBSD-
+     current for PS/2 mices.
 
-4.  Installing the Binaries
+   o MTRR Write Combining is enabled uner post 2.6 OpenBSD-current.
 
-Refer to section 5 of the Release Notes  for detailed installation instruc-
-tions.
+See the Release Notes for non-OS dependent new features in XFree86 3.9.17
 
-5.  Configuring X for Your Hardware
+4.  Configuring X for Your Hardware
 
 The /etc/XF86Config file tells the X server what kind of monitor, video card
 and mouse you have.  You must create it to tell the server what specific
 hardware you have.
 
-The easiest way to create this file is to run the XF86Setup utility as root.
-Refer to QuickStart.doc for details about its use.
-
 You'll need info on your hardware:
 
    o Your mouse type, baud rate and its /dev entry.
@@ -76,7 +64,7 @@ ual page.
 Once you've set up a XF86Config file, you can fine tune the video modes with
 the xvidtune utility.
 
-5.1  About mouse configuration
+4.1  About mouse configuration
 
 If your serial mouse does not work try using kermit or tip to connect to the
 mouse serial port and verify that it does indeed generate characters.
@@ -95,53 +83,9 @@ with a "3D" roller).
 
 See README.mouse  for general instruction on mouse configuration in XFree86.
 
-5.2  Other input devices
-
-XFree86  supports the dynamic loading of drivers for external input devices
-using the XInput extension. Currently supported devices are:
-
-   o Joystick (xf86Jstk.so)
-
-   o Wacom tablets (Wacom IV protocol only, xf86Wacom.so)
-
-   o SummaSketch tablets (xf86Summa.so)
-
-   o Elographics touchscreen (xf86Elo.so)
-
-To use a specific device, add the line
-
-     load "module"
-
-in the Module section of XF86Config, where module is the name of the .so file
-corresponding to your device.  You also need to set up a XInput section in
-XF86Config.  Refer to the XF86Config(5) man page for detailed configuration
-instructions.
+5.  Running X
 
-You can then change the device used to drive the X pointer with the xset-
-pointer(1) command.
-
-For joystick support, you'll need to enable the joystick device driver in the
-kernel.  See joy(4) for details.
-
-5.3  Configuring PEX and XIE extensions
-
-The PEX and XIE extensions are  supported as external modules.  If you want
-to have access to these extensions, add the following lines to the Module
-section of XF86Config:
-
-        load    "pex5.so"
-        load    "xie.so"
-
-6.  Running X
-
-8mb of memory is a recommended minimum for running X.  The server, window
-manager and an xterm take about 4 Mb of memory themselves.  On a 4Mb system
-that would leave nothing left over for other applications like gcc that
-expect a few meg free.  X will work with 4Mb of memory, but in practice com-
-pilation while running X can take 5 or 10 times as long due to constant pag-
-ing.
-
-6.1  Starting xdm, the display manager
+5.1  Starting xdm, the display manager
 
 To start the display manager, log in as root on the console and type: ``xdm
 -nodaemon''.
@@ -162,7 +106,7 @@ console device for the X server:
 Note that the binary distributions of XFree86 for OpenBSD don't include sup-
 port for the XDM-AUTHORIZATION-1 protocol.
 
-6.2  Running X without the display manager
+5.2  Running X without the display manager
 
 The easiest way for new users to start X windows is to type: ``startx >&
 startx.log''.  Error messages are lost unless you redirect them because the
@@ -172,14 +116,14 @@ To get out of X windows, type: ``exit'' in the console xterm.  You can cus-
 tomize your X by creating .xinitrc, .xserverrc, and .twmrc files in your home
 directory as described in the xinit and startx man pages.
 
-7.  Kernel Support for X
+6.  Kernel Support for X
 
 To make sure X support is enabled under  OpenBSD, the following line must be
 in your config file in /sys/arch/i386/conf:
 
      options XSERVER
 
-7.1  Console drivers
+6.1  Console drivers
 
 The server supports the two standard  OpenBSD/i386 console drivers: pccons
 and pcvt. They are detected at runtime and no configuration of the server
@@ -188,7 +132,7 @@ itself is required.
 The pcvt console driver is the default in OpenBSD.  It offers several virtual
 consoles and international keyboard support.
 
-7.2  Aperture Driver
+6.2  Aperture Driver
 
 By default OpenBSD includes the BSD 4.4 kernel security feature that disable
 access to the /dev/mem device when in multi-users mode. But XFree86 servers
@@ -199,46 +143,20 @@ erated servers can take advantage of it, but do not require it.  Some drivers
 in the SVGA server require linear memory access too, notably the Matrox
 driver.
 
-The preferred  way to allow XFree86 to access linear memory is to use the
-aperture driver
-
-Ths step is highly dependent from your exact operating system version:
-
-   o  OpenBSD 2.0
-
-     Use the aperture driver from /usr/lkm:
-
-     add the following lines to the end of /etc/rc.local:
+OpenBSD now requires the aperture driver to be enabled for all X servers,
+because the aperture driver also controls access to the I/O ports of the
+video boards.
 
-           KERNDIR=/usr/lkm
-           if [ -f ${KERNDIR}/ap.o ]; then
-             modload -o ${KERNDIR}/ap -e ap -p \
-             ${KERNDIR}/apinstall ${KERNDIR}/ap.o
-           fi
+The aperture driver is part of the kernel.  Add 'option APERTURE' to your
+kernel configuration file, build and install the new kernel and run ./MAKEDEV
+std in /dev. Edit /etc/sysctl.conf to set the variable machdep.allowaperture
+to 1.
 
-   o  OpenBSD 2.1, 2.2
-
-     Uncomment the lines loading the aperture driver from /etc/rc.securelevel
-
-   o  OpenBSD 2.3
-
-     The aperture driver is part of the kernel.  Add 'option APERTURE' to
-     your kernel configuration file, build and install the new kernel and run
-     ./MAKEDEV std in /dev. Edit /etc/sysctl.conf to set the variable
-     machdep.allowaperture to 1.
-
-   o  OpenBSD 2.4 and later
-
-     OpenBSD now requires the aperture driver to be enabled for all X
-     servers, because the aperture driver also controls access to the I/O
-     ports of the video boards.
-
-After doing that, reboot your system. XFree86 will auto-detect the aperture
-driver if available.
-
-Warning: if you boot another kernel than /bsd, loadable kernel modules can
-crash your system. Always boot in single user mode when you want to run
-another kernel.
+Another (less recommended) way to enable linear memory access is to disable
+the kernel security feature by adding ``option INSECURE'' in your kernel con-
+figuration file and build a new kernel.  In OpenBSD 2.2 and later, you will
+also need to comment out the line initializing securelevel to 1 in
+/etc/rc.securelevel.
 
      Caveat: the aperture driver only allows one access at a time (so
      that the system is in the same security state once X is launched).
@@ -246,13 +164,7 @@ another kernel.
      the first one will have linear memory access.  Use 'option INSE-
      CURE' if you need more that one X server at a time.
 
-Another (less recommended) way to enable linear memory access is to disable
-the kernel security feature by adding ``option INSECURE'' in your kernel con-
-figuration file and build a new kernel.  In OpenBSD 2.2 and later, you will
-also need to comment out the line initializing securelevel to 1 in
-/etc/rc.securelevel.
-
-7.3  MIT-SHM
+6.3  MIT-SHM
 
 OpenBSD supports System V shared memory. If XFree86 detects this support in
 your kernel, it will support the MIT-SHM extension.
@@ -266,11 +178,11 @@ To add support for system V shared memory to your kernel add the lines:
 
 to your kernel config file.
 
-8.  Rebuilding the XFree86 Distribution
+7.  Rebuilding the XFree86 Distribution
 
-The server link kit allow you to rebuild just the X server with a minimum
-amount of disk space.  Just unpack it, make the appropriate changes to the
-xf86site.def, type ``./mkmf'' and ``make'' to link the server.  See
+The server developper's kit allow you to rebuild just the X server with a
+minimum amount of disk space.  Just unpack it, make the appropriate changes
+to the xf86site.def, type ``./mkmf'' and ``make'' to link the server.  See
 /usr/X11R6/lib/Server/README for more info.
 
 See INSTALL for instructions on unbundling and building the source distribu-
@@ -280,7 +192,7 @@ You should configure the distribution by editing xc/config/cf/host.def
 before compiling.  To compile the sources, invoke ``make World'' in the xc
 directory.
 
-8.1  Console drivers
+7.1  Console drivers
 
 XFree86 has a configuration option to select the console drivers to use in
 xf86site.def:
@@ -296,21 +208,10 @@ xf86site.def:
 If you don't define XFree86ConsoleDefines in xf86site.def the pccons and pcvt
 drivers will be supported.
 
-8.2  Building on other architectures
+7.2  Building on other architectures
 
 XFree86 also compiles on other OpenBSD architectures.
 
-The XFree86 servers can also been built on OpenBSD/mips. The S3 server has
-been tested on an Acer Mips system with a S3/928 board. Contact Per Fogel-
-strom (pefo@OpenBSD.org) for details.
-
-The Xsun server patches from Dennis Ferguson and Matthew Green for NetBSD
-have been integrated in xc/programs/Xserver/hw/sun. The Xsun server can be
-built on the sparc and the sun3.
-
-The client side of XFree86 also builds on the alpha, pmax, amiga, mac68k and
-mvme68k architectures.
-
 Problems with this port should be reported directly to the OpenBSD mailing
 lists rather than to the xfree86 mailing list.
 
@@ -320,7 +221,7 @@ tree to rebuild from sources.  The OpenBSD X11 source tree is available by
 anoncvs from all OpenBSD anoncvs servers. See http://www.openbsd.org/anon-
 cvs.html for details on anoncvs.
 
-9.  Building New X Clients
+8.  Building New X Clients
 
 The easiest way to build a new client (X application) is to use xmkmf if an
 Imakefile is included in the sources.  Type ``xmkmf -a'' to create the Make-
@@ -328,9 +229,15 @@ files, check the configuration if necessary and type ``make''.  Whenever you
 install additional man pages you should update whatis.db by running ``make-
 whatis /usr/X11R6/man''.
 
-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.3 1999/08/23 06:38:50 dawes Exp $
+9.  Thanks
+
+Many thanks to all people who contributed to make XFree86 work on *BSD, in
+particular, David Dawes, Pace Willison, Amancio Hasty, Christoph Robitschko,
+Nate Williams, Rod Grimes, Jack Velte and Michael Smith.
+
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.5 1999/11/26 00:51:51 dawes Exp $
 
      $XConsortium$
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD,v 1.5 1999/08/23 07:03:46 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.OpenBSD,v 1.6 1999/11/26 00:58:23 dawes Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.SiS b/xc/programs/Xserver/hw/xfree86/doc/README.SiS
index 897c4cf5a..6b50e1e6c 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/README.SiS
+++ b/xc/programs/Xserver/hw/xfree86/doc/README.SiS
@@ -7,7 +7,7 @@
 1.  Introduction
 
 This driver was primarily written for the SiS6326 and SiS530 by Alan Houri-
-hane.  It also works on 5597/5598 chips, and probably on older SiS862XX fam-
+hane.  It also works on 5597/5598 chips, and probably on older SiS862X5 fam-
 ily.
 
 The driver supports :
@@ -24,8 +24,10 @@ The driver supports :
 
 2.  Supported chips
 
-     SiS 530, SiS 86c201, SiS 86c202, SiS 86c2x5, SiS 5597/5598, SiS
-     6326
+     SiS 530, SiS 86c2x5, SiS 5597/5598, SiS 6326
+
+This driver needs linear framebuffer support in the card. Because this SiS
+86C201 and 86C202 based cards don't work with this driver.
 
 Color expansion is not supported by the engine in 16M-color graphic mode.
 
@@ -101,8 +103,6 @@ sider several points:
 
 5.  Troubleshooting
 
-6326 based cards with more than 4Mb of RAM probably don't work.
-
 The generic VGA driver don't work with 6326, so XF86Setup can't be used for
 this card. Please use xf86config instead.
 
@@ -111,7 +111,7 @@ screen. Lowering dotclock in that case could solve the problem.
 
 Document based on 3.3 version written by Xavier Ducoin.
 
-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.5 1999/07/19 13:36:21 dawes Exp $
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.6 1999/10/13 04:21:08 dawes Exp $
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.SiS,v 3.10 1999/07/19 14:44:23 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.SiS,v 3.11 1999/10/14 03:31:24 dawes Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/README.ati b/xc/programs/Xserver/hw/xfree86/doc/README.ati
index 5b0ddf734..5eee93fb3 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/README.ati
+++ b/xc/programs/Xserver/hw/xfree86/doc/README.ati
@@ -2,7 +2,7 @@
 
                             Marc Aurele La France
 
-                                 1999 July 8
+                               1999 October 25
 
                                   Abstract
 
@@ -74,7 +74,8 @@ sent:
         Mach64 series:  88800GX-C, 88800GX-D, 88800GX-E, 88800GX-F, 88800CX,
                         264CT, 264ET, 264VT, 264GT (3D Rage), 264VT-B, 264VT3,
                         264VT4, 264GT-B (3D Rage II), 3D Rage IIc, 3D Rage Pro,
-                        3D Rage LT, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC
+                        3D Rage LT, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC,
+                        3D Rage Mobility
 
 The driver also supports 32K, 64K and 16M-colour modes on the 264xT and 3D
 Rage series of adapters using the accelerator CRTC (but not the VGA CRTC).
@@ -366,14 +367,39 @@ clocks, the second of which will be assumed to be 28.322MHz.  You can include
 up to four clock frequencies in your XF86Config to specify the actual values
 used by the adapter.  Any more will be ignored.
 
-5.7  Option ``nolinear''
+5.7  Option ``crt_screen''
+
+This specification is only effective when the driver detects that the
+adapter's BIOS has initialized both the digital flat panel and CRT inter-
+faces.  In such a situation, the driver will normally drive the panel and
+disable the CRT.  This specification causes the driver to disable the digital
+flat panel and display the screen image on the CRT instead.
+
+5.8  Option ``nolinear''
 
 By default, the driver will enable a linear video memory aperture for
 256-colour and higher depth modes if it is also using a Mach64 accelerator
 CRTC or an integrated Mach64 graphics chip.  This option disables this linear
 aperture.
 
-5.8  MemBase address
+5.9  Option ``shadowfb''
+
+If this option is enabled, the driver will cause the CPU to do each drawing
+operation first into a shadow frame buffer in system virtual memory and then
+copy the result into video memory.  If this option is not active, the CPU
+will draw directly into video memory.  Enabling this option is beneficial for
+those systems where reading from video memory is, on average, slower than the
+corresponding read/modify/write operation in system virtual memory.  This is
+normally the case for PCI or AGP adapters, and, so, this option is enabled by
+default.  For other bus types, the default behaviour is to disable this
+option.
+
+Note that, due to various limitations, this option is forcibly disabled when
+a linear video memory aperture is not enabled, or when the frame buffer depth
+is less than 8.  The use of video acceleration, when implemented in a future
+driver release, will also disable frame buffer shadowing.
+
+5.10  MemBase address
 
 This specification is only effective for non-PCI Mach64 adapters, and is used
 to override the CPU address at which the adapter will map its video memory.
@@ -405,11 +431,6 @@ driver.  They include:
      bug in kernels 2.0.31 or earlier that prevents proper APM operation.
      Upgrade to a more recent kernel or disable APM support.
 
-     The TV port on some Mach64 adapters needs to be disabled using an ATI
-     utility that might or might not be supplied with the adapter.  This
-     problem is still under investigation.  The only known workaround is to
-     ensure no cable is connected to the adapter's TV connector on bootup.
-
    o When using a Mach64's accelerator CRTC, the virtual resolution must be
      less than 8192 pixels wide.  The VGA CRTC further limits the virtual
      resolution width to less than 4096 pixels, or to less than 2048 pixels
@@ -428,11 +449,10 @@ driver.  They include:
      CRTC.
 
    o Interlaced modes are not supported on 18800-x and 28800-x adapters when
-     using a virtual resolution that is 2048 pixels or wider.  This is yet
-     another hardware limitation that cannot be circumvented.  For now, the
-     driver prevents the occurrence of this problem by restricting virtual
-     resolutions to be less than 2048 pixels wide, even when no interlaced
-     modes are specified.
+     using a virtual resolution that is 2048 pixels or wider.  When using a
+     18800-x with 256kB of video memory in 256-colour modes, this limit is
+     reduced to 1024.  This is yet another hardware limitation that cannot be
+     circumvented.
 
    o Video memory banking does not work in monochrome and 16-colour modes on
      18800-x adapters.  This appears to be another hardware limit, but this
@@ -542,7 +562,7 @@ tional colour depths, and so on.  This is the version found in XFree86 3.3.2,
 Version 5 is an almost complete restructuring of version 4 to fit in the new
 driver API of XFree86 4.0.
 
-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.25 1999/08/21 13:48:29 dawes Exp $
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.28 1999/10/26 15:58:15 tsi Exp $
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.ati,v 3.40 1999/08/22 05:35:49 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.ati,v 3.43 1999/10/26 16:56:29 tsi Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/RELNOTES b/xc/programs/Xserver/hw/xfree86/doc/RELNOTES
index 81c795b44..9befeba96 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/RELNOTES
+++ b/xc/programs/Xserver/hw/xfree86/doc/RELNOTES
@@ -1,15 +1,15 @@
-                    Release Notes for XFree86[tm] 3.9.16
+                    Release Notes for XFree86[tm] 3.9.17
 
                           The XFree86 Project, Inc
 
-                               31 August 1999
+                               31 December 1999
 
                                   Abstract
 
      This document contains some information about the features present
-     in XFree86 3.9.16 and their status.
+     in XFree86 3.9.17 and their status.
 
-1.  Summary of new features in 3.9.16 compared with 3.9.15.
+1.  Summary of new features in 3.9.17 compared with 3.9.16.
 
 This section contains a brief summary of what has changed since the previous
 snapshot.  Unfortunately, only a small number of changes are listed here.
@@ -18,7 +18,58 @@ grams/Xserver/hw/xfree86 directory in the source tree.  The sections that
 follow this one have details of features that are new to the pre-4.0 snapshot
 series.
 
-   o The "apm" driver has been updated.  See the APM section (section 2.11.1,
+   o The 3dfx driver is now supported by the DRI.
+
+   o Tiny-X for the Itsy has been added.
+
+   o Significant font and font server enhancements.
+
+   o New driver for ATI Rage 128.  The driver is called "r128".
+
+   o Xterm enhancements and fixes.
+
+   o DPS support hooks have been added.
+     Display Postscript support is being maintained outside of the
+     server tree due to licensing issues.  A web page for DPS resources
+     under XFree86 will be available shortly.
+
+   o DRI enhancements including Mesa update to version 3.2, full support
+     and fifo code for 3dfx hardware, and device driver updates for
+     Linux 2.3 kernels.
+
+   o Significant enhancements to Xv including support for XvImages
+     (YUV XImages).
+
+   o Add initial VESA VBE support including initialization and DDC.
+
+   o Several PCI enhancements.
+
+   o "SilkenMouse" (asynchronous pointer handling) for smoother mouse movement.
+
+   o Add GeForce/Quadro support to the NVIDIA driver.
+
+   o Int10 "soft-booting" support for Linux.
+
+   o Resource allocation infrastructure added.
+
+   o Syntax of the layout section has changed to make multi-head
+     configuration easier.
+
+   o Some Xinerama bug fixes.
+
+   o The DGA 2.0 interface is mostly finalized and includes some
+     preliminary documentation.
+
+   o ViRGE MX Melco BIOS support has been added.
+
+   o Keyboard AutoRepeat now works correctly on Linux.  This means
+     that the AutoRepeat keyword in XF86Config is now obeyed; you may be
+     more comfortable using "250 30" rather than the default setting of
+     "500 5".
+
+2.  Summary of new features in 3.9.16 compared with 3.9.15.
+
+   o The "apm" driver has been updated.  See the APM section (section 3.12.1,
      page 1) below.
 
    o A driver for NVIDIA chipsets is now included.  The driver is called
@@ -37,20 +88,20 @@ series.
 
    o Some preliminary support for programming modes has been added to xedit.
 
-2.  X server
+3.  X server
 
 Unlike XFree86 3.3.x where there are multiple X server binaries, each of
-which drive different hardware, XFree86 3.9.16 has a single X server binary
+which drive different hardware, XFree86 3.9.17 has a single X server binary
 (called XFree86).  This binary can either have one or more video drivers
 linked in statically, or, more usually, dynamically load the video drivers
 and other modules that are needed.
 
-XFree86 3.9.16 has X server support for most UNIX(R) and UNIX-like operating
+XFree86 3.9.17 has X server support for most UNIX(R) and UNIX-like operating
 systems on Intel/x86 platforms, plus support for Linux on Alpha and PowerPC
 platforms.  Support for additional architectures and operating systems is
 planned for future releases.
 
-2.1  Loader and Modules
+3.1  Loader and Modules
 
 The XFree86 X server has a built-in run-time loader, donated by Metro Link
 <URL:http://www.metrolink.com>.  This loader can load normal object files and
@@ -64,7 +115,7 @@ even OS/2.  One of the main benefits of this is that when modules are
 updated, they don't need to be recompiled for each different operating sys-
 tem.
 
-The loader in version 3.9.16 has support for Intel (x86), Alpha and PowerPC
+The loader in version 3.9.17 has support for Intel (x86), Alpha and PowerPC
 platforms.  It also has preliminary support for Sparc platforms.
 
 The X server makes use of modules for video drivers, X server extensions,
@@ -87,7 +138,7 @@ Note about module security
      4.0 is released, we hope to have implemented a method for sign-
      ing/verifying modules that we provide.
 
-2.2  Configuration File
+3.2  Configuration File
 
 The X server configuration file format has been extended to handle some of
 the new functionality.  The xf86config utility can be used to generate a
@@ -185,8 +236,16 @@ The main changes are:
                    Driver      "mouse"
                    Option      "Protocol"   "PS/2"
                    Option      "Device"     "/dev/mouse"
+		   SampleRate  80
                EndSection
 
+     Note: Additional sample rates have been added for some mice.
+           Matching the mouse sampling rate with the vertical refresh
+           rate can yield very noticeable improvements in smoothness of
+           pointer event driven operations such as window moves and
+           scrolling.
+
+
    o The Monitor section is mostly unchanged.  The main difference is that a
      set of VESA modes is defined internally in the server, and so for most
      monitors, it isn't necessary to specify any modes explicitly in the Mon-
@@ -223,17 +282,20 @@ The main changes are:
                Section "ServerLayout"
                    Identifier  "Layout 1"
                    Screen      "MGA 1"
-                   Screen      "MGA 2"
+                   Screen      "MGA 2" RightOf "MGA 1"
                    InputDevice "Keyboard 1" "CoreKeyboard"
                    InputDevice "Mouse 1"    "CorePointer"
                    InputDevice "Mouse 2"    "SendCoreEvents"
                    Option      "BlankTime"  "5"
                EndSection
 
+     See the document xc/programs/Xserver/hw/xfree86/doc/DESIGN for a
+     more detailed explanation of the new ServerLayout section syntax.
+
 The config file search patch has been extended, with the directories /etc/X11
 and /usr/X11R6/etc being added.
 
-2.3  Command Line Options
+3.3  Command Line Options
 
 The following new X server command line options have been added:
 
@@ -347,13 +409,13 @@ The following X server command line options have been changed since 3.3.x:
           This makes it possible for users to choose from multiple
           config files that the the sysadmin has provided.
 
-2.4  XAA
+3.4  XAA
 
 The XFree86 Acceleration Architecture (XAA) has been completely rewritten
 from scratch.  Most drivers implement acceleration by making use of the XAA
 module.
 
-2.5  Multi-head
+3.5  Multi-head
 
 Some multi-head configurations are supported in this release, primarily with
 multiple PCI/AGP cards.  However, this is an area that is still being worked
@@ -369,7 +431,7 @@ slot, or by changing the system BIOS's preference for the primary card).  We
 are investigating options for ``soft-booting'' secondary video cards to deal
 with this problem, and we've had some very encouraging results.
 
-2.6  Xinerama
+3.6  Xinerama
 
 Xinerama is an X server extension that allows multiple physical screens to
 behave as a single screen.  With traditional multi-head in X11, windows can-
@@ -387,9 +449,6 @@ we expect it to be improved further in future snapshots.
 
 Known problems:
 
-   o The Xinerama layout doesn't match the layout specified in the config
-     file's ServerLayout section.
-
    o It appears that there are still some bugs that cause unexpected
      behaviour from time to time.
 
@@ -398,13 +457,15 @@ Known problems:
      way.  This is an issue that needs to be dealt with in the individual
      window managers, and isn't specifically an XFree86 problem.
 
-2.7  DGA version 2
+3.7  DGA version 2
 
-The DGA extension has been reworked.  The version present in this snapshot is
-preliminary, not documented, not implemented by many drivers, and subject to
-further change without notice.  Compatibility with version 1.0 is provided.
+DGA 2.0 is nearly completed but still not implemented by all drivers.
+Preliminary documentation for the client libraries can be found in the
+xc/programs/Xserver/hw/xfree86/DGA document.  Some degree of backwards
+compatibility with version 1.0 is provided.
 
-2.8  DDC
+
+3.8  DDC
 
 The VESA(R) Display Data Channel (DDC[tm]) standard (related to, but separate
 from, the VESA(R) Plug and Display standard) allows the monitor to tell the
@@ -412,7 +473,7 @@ video card (or on some cases the computer directly) about itself; particu-
 larly the supported screen resolutions and refresh rates.
 
 Partial or complete DDC support is available in the following hardware mod-
-ules (this list needs to be verified):
+ules:
 
    o APM
 
@@ -456,7 +517,7 @@ the monitor gamma (brightness) curve, and the screen size and pitch.
      screen dimensions with the "DisplaySize" keyword in the "Monitor" sec-
      tion of the config file.
 
-2.9  GLX and the Direct Rendering Infrastructure (DRI)
+3.9  GLX and the Direct Rendering Infrastructure (DRI)
 
 Precision Insight <URL:http://www.precisioninsight.com> has been provided
 with funding and support from Red Hat <URL:http://www.redhat.com> and SGI
@@ -470,11 +531,20 @@ Rendering Infrastructure.  Direct Rendering provides a highly optimized path
 for sending 3D data directly to the graphics hardware.  This release demon-
 strates a sample implementation of direct rendering <URL:http://www.preci-
 sioninsight.com/demo.html> by providing a single path of 3D hardware acceler-
-ated rendering for the GMX2000 graphics card.  Future releases will support
-much broader implementations of hardware accelerated direct rendering on a
-wide range of 3D capable graphics devices.
+ated rendering for the GMX2000 and 3dfx voodoo graphics cards.  Future
+releases will support much broader implementations of hardware accelerated
+direct rendering on a wide range of 3D capable graphics devices.
+
+3.10  X-Video Extension (Xv)
+   
+An XvQueryPortAttributes function has been added as well as
+support for XvImages.  XvImages are XImages in alternate color spaces
+such as YUV and can be passed to the server through shared memory
+segments.  This allows clients to display YUV data with high quality 
+hardware scaling and filtering.   XvImages are only supported
+by the Matrox G200/G400 cards at the moment.
 
-2.10  Other extensions
+3.11  Other extensions
 
 The XFree86-Misc extension has not been fully ported to the new server archi-
 tecture yet.  This should be completed in a future snapshot.
@@ -487,9 +557,9 @@ The new xgamma utility makes use of this feature.  Compatibility with the
 3.3.x version of the extension is provided.  The missing parts of this exten-
 sion and some new features should be completed in a future snapshot.
 
-2.11  Drivers
+3.12  Drivers
 
-XFree86 3.9.16 includes the following drivers:
+XFree86 3.9.17 includes the following drivers:
 
                     +------------+----------------------+
                     |Driver Name | Description          |
@@ -505,6 +575,7 @@ XFree86 3.9.16 includes the following drivers:
                     |mga         | Matrox               |
                     |neomagic    | NeoMagic             |
                     |nv          | NVIDIA               |
+                    |r128        | ATI Rage 128         |
                     |rendition   | Rendition            |
                     |s3virge     | S3 ViRGE             |
                     |sis         | SiS                  |
@@ -515,7 +586,7 @@ XFree86 3.9.16 includes the following drivers:
                     |vga         | Generic VGA          |
                     +------------+----------------------+
 
-2.11.1  APM
+3.12.1  APM
 
 The driver apm is for Alliance AT3D/AT25 based boards.  The driver is still
 in development. I hope to be able to correct the errors I find.  The Rush
@@ -523,11 +594,11 @@ extension should be ready for the next snapshot; I can do better memory man-
 agement, but I'll need time. If someone can help me, feel free to drop an
 email to <grenie@lami.univ-evry.fr>
 
-2.11.2  Chips & Technologies
+3.12.2  Chips & Technologies
 
 Information about the C&T driver can be found in README.chips.
 
-2.11.3  s3virge
+3.12.3  s3virge
 
 The s3virge driver is a port of the 3.3.3.1 SVGA S3 ViRGE driver.  As such it
 should be as stable and functional as previous XFree86 releases.  There are a
@@ -548,15 +619,13 @@ Outstanding items not implemented or fully tested:
 
    o DGA support is implemented, but preliminary and untested.
 
-   o ViRGE MX Melco BIOS support has not been ported yet.
-
-2.11.4  TGA
+3.12.4  TGA
 
 The TGA driver is now accelerated and supports both 8 and 32 plane frame-
 buffers.  It is known to work under Linux/Alpha.  Please see the
 README.DECtga file for further information.
 
-2.11.5  Matrox
+3.12.5  Matrox
 
 The MGA driver supports the same range or hardware as XFree86 3.3.4, but has
 a number of enhancements including multi-head support and support for over-
@@ -570,24 +639,53 @@ feature.  By default, the color key for the overlays is 255, but this can be
 changed with the "ColorKey" option to work around problems in specific pro-
 grams.  Valid values for the key are 2-255.
 
-Option "OverclockMem" will raise the memory clock on the G200.  Matrox
-doesn't recommend deviating from the BIOS defaults but we find that some
-hardware shows static during graphics operations in high resolutions/depths
-when run at the regular clocks so this option is needed for some cards (it
-also improves performance).  Beware, some hardware experiences difficultly
-restoring the console when this option is used.
+This release contains performance enhancements for the G400 and particularly
+for the G400 MAX.  It also includes XvImage support for G200/G400 chips and
+improved memory autodetection support.
 
 Further information can be found in the mga man page.
 
-2.11.6  ATI
+3.12.6  ATI
 
 Information about the ATI driver can be found in README.ati <URL:ati.html>.
 The current version is not accelerated.  Acceleration support is planned for
 a future snapshot.
 
-3.  X libraries and clients
+3.12.7  NVIDIA
+
+The "nv" driver supports all Riva TNT accelerators as well as the
+new GeForce and Quadro accelerators.  3.9.17 adds DGA 2.0 support
+and performance improvements as well as resolving some rendering
+correctness issues.
+ 
+Further information can be found in the nv man page.
+
+3.12.8 Glide
+
+This driver is for Voodoo 1 and Voodoo 2 boards. It runs X on top of
+the 3DFX Glide API (where this is available, like for Linux). You need
+to have Glide 2.x installed before you can run this driver. This
+driver uses no hardware acceleration (since there is no 2D
+acceleration in these boards) but is rather quick anyway since the CPU
+renders to local RAM which is then copied block-wise to the
+board. Unfortunately the Voodoo 1/2 boards are rather limited in
+resolution. The Voodoo 1 can do 800x600 and the Voodoo 2 can do
+1024x768 at best, but still it has some use as a second head in 
+Xinerama or multihead mode.
+
+16 and 24 bpp modes are supported (24 bit in 32-bit sparse-packed
+mode).
+
+Further information about this driver can be found in the 'glide' driver
+manpage for XFree86. You will not get this driver running before
+reading this manpage.
+
+For Voodoo Banshee and Voodoo 3 boards or later: Please use the tdfx
+driver which talks directly to the hardware and is much faster.
+
+4.  X libraries and clients
 
-3.1  Xaw
+4.1  Xaw
 
 Two versions of the Xaw library are provided in this release. A version with
 bug fixes and a few binary compatible improvements and a new version with
@@ -652,11 +750,11 @@ Bug fixes:
    o Several bugs were fixed in the text code, while some code was rewritten
      from scratch.
 
-3.2  Xpm
+4.2  Xpm
 
 Version 3.4k of the Xpm (X pixmap) library is now integrated into XFree86.
 
-3.3  xterm
+4.3  xterm
 
 New Features:
 
@@ -737,7 +835,7 @@ Bug fixes/improvements:
    o Add test/demo scripts for double size characters, font switching, screen
      resizing and colors.
 
-3.4  xedit
+4.4  xedit
 
 Xedit have been changed to use most of the new features added to the new ver-
 sion of the Xaw library, and some xedit only features were added. Emacs users
@@ -780,18 +878,18 @@ xedit. These include:
           this snapshot only to show what the new text widget capabilities
           can do.
 
-4.  Fonts and Internationalisation
+5.  Fonts and Internationalisation
 
 Details about the font support in this version of XFree86 can be found in the
 README.fonts document.
 
-4.1  TrueType support
+5.1  TrueType support
 
 This version of XFree86 comes with two TrueType backends, known as `xfsft'
 (the "freetype" module) and `X-TrueType' (the "xtt" module).  Both of these
 backends are based on the FreeType library.
 
-4.2  CID font support
+5.2  CID font support
 
 Support for CID-keyed fonts is included in this version of XFree86.  The CID-
 keyed font format was designed by Adobe Systems <URL:http://www.adobe.com>
@@ -799,7 +897,7 @@ for fonts with large character sets.  The CID-keyed font support in XFree86
 was donated by SGI <URL:http://www.sgi.com>.  See the LICENSE document for a
 copy of the CID Font Code Public License.
 
-4.3  Internationalisation of the scalable font backends
+5.3  Internationalisation of the scalable font backends
 
 A new ``fontenc'' layer has been added to allow the scalable font backends to
 use a common method of font re-encoding.  This re-encoding makes it possible
@@ -808,7 +906,7 @@ layer is used by the Type1 and Speedo backends and the `xfsft' version of the
 TrueType backend.  The `X-TrueType' version of the TrueType backend uses a
 different re-encoding method based on loadable encoding modules.
 
-4.4  Unicode support
+5.4  Unicode support
 
 What is included:
 
@@ -838,18 +936,18 @@ Known problems:
    o ISO 10646 Level 2 combining characters not yet supported by xterm (will
      be needed for instance for the Thai script).
 
-5.  Miscellaneous
+6.  Miscellaneous
 
-5.1  Directory rearrangements
+6.1  Directory rearrangements
 
 Some changes to the installed XFree86 directory structure have been planned
 for 4.0.  Not all of these changes have been implemented in this snapshot,
 and they will appear in a future snapshot.  One important change that has
 been implemented is a modified search path for the X server's XF86Config
 file.  The details of this can be found above in the Configuration File (sec-
-tion 2.2, page 1) section.
+tion 3.2, page 1) section.
 
      Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.18 1999/08/31 08:39:09 dawes Exp $
 
 
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/RELNOTES,v 3.70 1999/08/31 08:42:05 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/RELNOTES,v 3.73 2000/01/03 15:19:06 robin Exp $
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml
index 67f2cbb7d..e17916541 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml
@@ -27,10 +27,16 @@
 
 <title>XFree86 X server ``New Design'' (DRAFT)
 <author>The XFree86 Project, Inc
-<date>Last modified 17 July 1999
+<date>Last modified 25 November 1999
+
+
+
+
+
+
 
 <ident>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.9 1999/07/18 03:26:51 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DESIGN.sgml,v 1.18 1999/12/17 03:02:26 mvojkovi Exp $
 </ident>
 
 
@@ -162,11 +168,15 @@ changes:
     the command line.  In the absence of this, a default will be chosen
     (the first one found).  The screen names may optionally be followed
     by a number specifying the preferred screen number, and optionally
-    by the names of the four screens adjacent to it.  The order of these
-    is top, bottom, left, right.  When no screen number is specified,
-    they are numbered according to the order in which they are listed.
-    Here is an example of a &k.serverlayout; section for two screens, with
-    the second located to the right of the first:
+    by information specifying the physical positioning of the screen,
+    either in absolute terms or relative to another screen (or screens).
+    When no screen number is specified, they are numbered according to
+    the order in which they are listed.  The old (now obsolete) method
+    of providing the positioning information is to give the names of
+    the four adjacent screens.  The order of these is top, bottom, left,
+    right.  Here is an example of a &k.serverlayout; section for two
+    screens using the old method, with the second located to the right
+    of the first:
 
     <code>
       Section "ServerLayout"
@@ -177,6 +187,49 @@ changes:
       EndSection
     </code>
 
+    The preferred way of specifying the layout is to explicitly specify
+    the screen's location in absolute terms or relative to another
+    screen.
+
+    In the absolute case, the upper left corner's coordinates are given
+    after the &s.key;Absolute&e.key; keyword.  If the coordinates are
+    omitted, a value of &s.code;(0,0)&e.code; is assumed.  An example
+    of absolute positioning follows:
+
+    <code>
+      Section "ServerLayout"
+        Identifier "Main Layout"
+        Screen     "Screen 1" 0 Absolute 0 0
+        Screen     "Screen 2" 1 Absolute 1024 0
+        Screen     "Screen 3" Absolute 2048 0
+      EndSection
+    </code>
+
+    In the relative case, the position is specified by either using one of
+    the following keywords followed by the name of the reference screen:
+
+    <quote>
+      &s.key;RightOf&nl;
+      LeftOf&nl;
+      Above&nl;
+      Below&nl;
+      Relative&e.key;
+    </quote>
+
+    When the &s.key;Relative&e.key; keyword is used, the reference screen
+    name is followed by the coordinates of the new screen's origin
+    relative to reference screen.  The following example shows how to use
+    some of the relative positioning options.
+
+    <code>
+      Section "ServerLayout"
+        Identifier "Main Layout"
+        Screen     "Screen 1" 0
+        Screen     "Screen 2" 1 RightOf "Screen 1"
+        Screen     "Screen 3" Relative "Screen 1" 2048 0
+      EndSection
+    </code>
+
 <sect1>Options
 <p>
 
@@ -906,7 +959,7 @@ is what &s.code;InitOutput()&e.code; does:
     exits with an appropriate message.
 
 
-<sect1>Check of Resource Control is Needed
+<sect1>Check if Resource Control is Needed
 <p>
 
     Determine if resource access control is needed.  This is the case
@@ -1105,9 +1158,9 @@ is what &s.code;InitOutput()&e.code; does:
     <quote><p>
     &s.code;Bool ChipEnterVT(int index, int flags)&e.code;
     <quote><p>
-      This function should map memory regions, initialise the current
-      video mode and initialise the viewport, turn on the HW cursor if
-      appropriate, etc.
+      This function should initialise the current video mode and
+      initialise the viewport, turn on the HW cursor if appropriate,
+      etc.
 
       Should it re-save the video state before initialising the video
       mode?
@@ -1116,11 +1169,38 @@ is what &s.code;InitOutput()&e.code; does:
 
     &s.code;void ChipLeaveVT(int index, int flags)&e.code;
     <quote><p>
-      This function should restore the saved video state and unmap the
-      memory regions.  If appropriate it should also turn off the HW
-      cursor, and invalidate any pixmap/font caches.
+      This function should restore the saved video state.  If
+      appropriate it should also turn off the HW cursor, and invalidate
+      any pixmap/font caches.
 
     </quote>
+
+    Optionally, &s.code;ChipLeaveVT()&e.code; may also unmap memory
+    regions.  If so, &s.code;ChipEnterVT()&e.code; will need to remap
+    them.  Additionally, if an aperture used to access video memory is
+    unmapped and remapped in this fashion, &s.code;ChipEnterVT()&e.code;
+    will also need to notify the framebuffer layers of the aperture's new
+    location in virtual memory.  This is done with a call to the screen's
+    &s.code;ModifyPixmapHeader()&e.code; function, as follows
+
+    <quote><p>
+    &s.code;(*pScreen->ModifyPixmapHeader)(pScrn->ppix,
+        &f.indent;-1, -1, -1, -1, -1, <it>NewApertureAddress</it>);&e.code;
+    <quote><p>
+        where the &s.code``ppix''&e.code; field in a ScrnInfoRec
+        points to the pixmap used by the screen's
+        &s.code;SaveRestoreImage()&e.code; function to hold the screen's
+        contents while switched out.
+
+    </quote>
+    </quote>
+
+    Currently, aperture remapping, as described here, should not be
+    attempted if the driver uses the &s.code;xf8_16bpp&e.code; or
+    &s.code;xf8_32bpp&e.code; framebuffer layers.  A pending
+    restructuring of VT switching will address this restriction in
+    the near future.
+
     </quote>
 
     Other layers may wrap the &s.code;ChipEnterVT()&e.code; and
@@ -1180,6 +1260,30 @@ but their presence is optional.
     </quote>
     </quote>
 
+<p>
+This function may also modify the effective timings and clock of the passed
+mode.  These have been stored in the mode's &s.code;Crtc*&e.code; and
+&s.code;SynthClock&e.code; elements, and have already been adjusted for
+interlacing, doublescanning, multiscanning and clock multipliers and dividers.
+The function should not modify any other mode field, unless it wants to modify
+the mode timings reported to the user by &s.code;xf86PrintModes()&e.code;.
+
+<p>
+The function is called once for every mode in the XF86Config Monitor section
+assigned to the screen, with &s.code;flags&e.code; set to
+&s.code;MODECHECK_INITIAL&e.code;.  It is subsequently called for every mode
+in the XF86Config Display subsection assigned to the screen, with
+&s.code;flags&e.code; set to &s.code;MODECHECK_FINAL&e.code;.  In the second
+case, the mode will have successfully passed all other tests.  In addition,
+the &s.code;ScrnInfoRec&e.code;'s &s.code;virtualX&e.code;,
+&s.code;virtualY&e.code; and &s.code;displayWidth&e.code; fields will have been
+set as if the mode to be validated were to be the last mode accepted.
+
+<p>
+In effect, calls with MODECHECK_INITIAL are intended for checks that do not
+depend on any mode other than the one being validated, while calls with
+MODECHECK_FINAL are intended for checks that may involve more than one mode.
+
 <sect1>Free screen data
 <p>
 
@@ -2878,7 +2982,19 @@ To use the colormap layer, a driver calls the
 
       </quote>
 
-      The colormap layer always reloads the palette after VT enters so it
+      &s.code;CMAP_LOAD_EVEN_IF_OFFSCREEN&e.code;
+      <quote><p>
+				    reload the colormap even if the screen
+				    is switched out of the server's VC.
+				    The palette is <it>not</it> reloaded when
+				    the screen is switched back in, nor after
+				    mode switches.  This is useful when the
+				    driver needs to keep track of palette
+				    changes.
+
+      </quote>
+
+      The colormap layer normally reloads the palette after VT enters so it
       is not necessary for the driver to save and restore the palette
       when switching VTs.  The driver must, however, still save the
       initial palette during server start up and restore it during 
@@ -3345,7 +3461,7 @@ The &s.code;XF86VideoAdaptorRec&e.code;:
 <quote><p>
 <verb>
 typedef struct {
-	unsigned char type; 
+	unsigned int type; 
 	int flags;
 	char *name;
 	int nEncodings;
@@ -3353,8 +3469,11 @@ typedef struct {
 	int nFormats;
 	XF86VideoFormatPtr pFormats;  
 	int nPorts;
-	XF86AttributeListPtr pAttributes;
 	DevUnion *pPortPrivates;
+	int nAttributes;
+	XF86AttributePtr pAttributes;
+	int nImages;
+	XF86ImagePtr pImages;
 	PutVideoFuncPtr PutVideo;
 	PutStillFuncPtr PutStill;
 	GetVideoFuncPtr GetVideo;
@@ -3363,6 +3482,8 @@ typedef struct {
 	SetPortAttributeFuncPtr SetPortAttribute;
 	GetPortAttributeFuncPtr GetPortAttribute;
 	QueryBestSizeFuncPtr QueryBestSize;
+	PutImageFuncPtr PutImage;
+	QueryImageAttributesFuncPtr QueryImageAttributes;
 } XF86VideoAdaptorRec, *XF86VideoAdaptorPtr;
 </verb>
 
@@ -3371,13 +3492,32 @@ typedef struct {
     
      &s.code;type&e.code;
      <quote><p>
-	This can be &s.code;XvInputMask&e.code;,
-	&s.code;XvOutputMask&e.code; or both OR'd together.  This refers
-	to the target drawable and is similar to a Window's
-	&s.code;class&e.code;.  &s.code;XvInputMask&e.code; indicates
-	that the adaptor can put video into a drawable.
-	&s.code;XvOutputMask&e.code; indicates that the adaptor can get
-	video from a drawable.
+	This can be any of the following flags OR'd together.
+
+	&s.code;XvInputMask&e.code;
+	&s.code;XvOutputMask&e.code;
+	<quote><p>
+	    These refer to the target drawable and are similar to a Window's 
+	    class. &s.code;XvInputMask&e.code; indicates that the adaptor
+	    can put video into a drawable.  &s.code;XvOutputMask&e.code;
+	    indicates that the adaptor can get video from a drawable.
+	</quote>
+
+	&s.code;XvVideoMask&e.code;
+	&s.code;XvStillMask&e.code;
+	&s.code;XvImageMask&e.code;
+	<quote><p>
+	    These indicate that the adaptor supports video, still or
+	    image primitives respectively.
+	</quote>
+
+	&s.code;XvWindowMask&e.code;
+	&s.code;XvPixmapMask&e.code;
+	<quote><p>
+	    These indicate the types of drawables the adaptor is capable
+	    of rendering into.  At the moment, Pixmap rendering is not
+	    supported and the &s.code;XvPixmapMask&e.code; flag is ignored.
+	</quote>
 
      </quote>
 
@@ -3388,10 +3528,13 @@ typedef struct {
 	&s.code;VIDEO_NO_CLIPPING&e.code;
 	<quote><p>
 	   This indicates that the video adaptor does not support
-	   clipping.  The driver will never receive Get/Put requests
+	   clipping.  The driver will never receive ``Put'' requests
 	   where less than the entire area determined by
 	   &s.code;drw_x&e.code;, &s.code;drw_y&e.code;,
 	   &s.code;drw_w&e.code; and &s.code;drw_h&e.code; is visible.
+	   This flag does not apply to ``Get'' requests.  Hardware
+	   that is incapable of clipping ``Gets'' may punt or get
+	   the extents of the clipping region passed to it.
 
 	</quote>
 
@@ -3403,17 +3546,28 @@ typedef struct {
 
 	</quote>
 
-	&s.code;VIDEO_EXPOSE&e.code;
+	&s.code;VIDEO_OVERLAID_STILLS&e.code;
 	<quote><p>
-	   This flag applies to &s.code;GetStill&e.code; and
-	   &s.code;GetVideo&e.code; only, it indicates the clip list
-	   shall contain obscured regions.  Note the source region will
-	   still be clipped against the screen bounds.  This flag is
-	   meant for showing all the contents of the [root] window, if
-	   the administrator has no hesitations regarding security.
+	   Implementing PutStill for hardware that does video as an
+	   overlay can be awkward since it's unclear how long to leave
+	   the video up for.  When this flag is set, StopVideo will be
+	   called whenever the destination gets clipped or moved so that
+	   the still can be left up until then.
 
 	</quote>
 
+	&s.code;VIDEO_OVERLAID_IMAGES&e.code;
+	<quote><p>
+	    Same as &s.code;VIDEO_OVERLAID_STILLS&e.code; but for images.
+	</quote>
+
+	&s.code;VIDEO_CLIP_TO_VIEWPORT&e.code;
+	<quote><p>
+	    Indicates that the clip region passed to the driver functions
+	    should be clipped to the visible portion of the screen in the
+	    case where the viewport is smaller than the virtual desktop.
+	</quote>
+
      </quote>
 
      &s.code;name&e.code;
@@ -3428,6 +3582,9 @@ typedef struct {
 	The number of encodings the adaptor is capable of and pointer
 	to the &s.code;XF86VideoEncodingRec&e.code; array.  The
 	&s.code;XF86VideoEncodingRec&e.code; is described later on.
+	For drivers that only support XvImages there should be an encoding
+	named "XV_IMAGE" and the width and height should specify
+	the maximum size source image supported.
 
      </quote>
 
@@ -3453,19 +3610,34 @@ typedef struct {
 	In the case where there may be many ports, this enables the
 	driver to know which port the request is intended for.  Most
 	commonly, this will contain a pointer to the data structure
-	containing information about the port.
+	containing information about the port.  In Xv, all ports on
+	a particular adaptor are expected to be identical in their
+	functionality.
 
      </quote>
 
-     &s.code;pAttributes&e.code;
+     &s.code;nAttributes&nl;
+     pAttributes&e.code;
      <quote><p>
-	There is an array of &s.code;XF86AttributeListRecs&e.code; with
-	an entry for each port.
+	The number of attributes recognized by the adaptor and a pointer to
+	the array of &s.code;XF86AttributeRecs&e.code;.  The
+	&s.code;XF86AttributeRec&e.code; is described later on.
 
      </quote>
 
+     &s.code;nImages&nl;
+     pImages&e.code;
+     <quote><p>
+	The number of &s.code;XF86ImageRecs&e.code; supported by the adaptor 
+	and a pointer to the array of &s.code;XF86ImageRecs&e.code;. The
+	&s.code;XF86ImageRec&e.code; is described later on.
+
+     </quote>
+
+
      &s.code;PutVideo PutStill GetVideo GetStill StopVideo
-     SetPortAttribute GetPortAttribute QueryBestSize&e.code;
+     SetPortAttribute GetPortAttribute QueryBestSize PutImage
+     QueryImageAttributes&e.code;
      <quote><p>
 	These functions define the DDX-&gt;driver interface.  In each
 	case, the pointer &s.code;data&e.code; is passed to the driver.
@@ -3473,40 +3645,47 @@ typedef struct {
 	fields are required except under the following conditions:
 
 	<enum>
-	 <item>&s.code;PutVideo&e.code; and &s.code;PutStill&e.code;
-	     are not required when the adaptor type does not contain
-	     &s.code;XvInputMask&e.code;.
+	 <item>&s.code;PutVideo&e.code;, &s.code;PutStill&e.code; and
+	     the image routines &s.code;PutImage&e.code; and 
+	     &s.code;QueryImageAttributes&e.code; are not required when the 
+	     adaptor type does not contain &s.code;XvInputMask&e.code;.
 
 	 <item>&s.code;GetVideo&e.code; and &s.code;GetStill&e.code;
 	     are not required when the adaptor type does not contain
 	     &s.code;XvOutputMask&e.code;.
 
+	 <item>&s.code;GetVideo&e.code; and &s.code;PutVideo&e.code;
+	     are not required when the adaptor type does not contain
+	     &s.code;XvVideoMask&e.code;.
+
+	 <item>&s.code;GetStill&e.code; and &s.code;PutStill&e.code;
+	     are not required when the adaptor type does not contain
+	     &s.code;XvStillMask&e.code;.
+
+	 <item>&s.code;PutImage&e.code; and &s.code;QueryImageAttributes&e.code;
+	     are not required when the adaptor type does not contain
+	     &s.code;XvImageMask&e.code;.
+
 	</enum>
 
-	These functions should return Success if the operation was
-	completed successfully.  They can return &s.code;XvBadAlloc&e.code;
-	otherwise.  Xv DDX will not call a Get/Put function while video
-	is active, rather issue a &s.code;StopVideo&e.code; call first.
+	With the exception of &s.code;QueryImageAttributes&e.code;, these
+	functions should return &s.code;Success&e.code; if the operation was
+	completed successfully.  They can return &s.code;XvBadAlloc&e.code; 
+	otherwise. &s.code;QueryImageAttributes&e.code; returns the size
+	of the XvImage queried.
 
-	Earlier versions of Xv DDX had a &s.code;ReclipVideo&e.code;
-	function, obsolete now.  The clip region will be passed directly
-	by the functions below.  If the &s.code;VIDEO_NO_CLIPPING&e.code;
-	flag is set, the &s.code;RegionPtr&e.code; should be ignored by
+	If the &s.code;VIDEO_NO_CLIPPING&e.code;
+	flag is set, the &s.code;clipBoxes&e.code; may be ignored by
 	the driver.  &s.code;ClipBoxes&e.code; is an &s.code;X-Y&e.code;
 	banded region identical to those used throughout the server.
-	The clipBoxes represent the visible portions of area determined
+	The clipBoxes represent the visible portions of the area determined
 	by &s.code;drw_x&e.code;, &s.code;drw_y&e.code;,
 	&s.code;drw_w&e.code; and &s.code;drw_h&e.code; in the Get/Put
 	function.  The boxes are in screen coordinates, are guaranteed
-	not to overlap and an empty region will be passed only to
-	&s.code;GetVideo&e.code;, once.  This to notify the driver the
-	primitive is totally obscured now.  A &s.code;StopVideo&e.code;
-	call will immediately follow nevertheless.  In the case where
-	the &s.code;VIDEO_INVERT_CLIPLIST&e.code; flag is set,
+	not to overlap and an empty region will never be passed.  
+	If the driver has specified &s.code;VIDEO_INVERT_CLIPLIST&e.code;,
 	&s.code;clipBoxes&e.code; will indicate the areas of the primitive
-	which are obscured rather than the areas visible.  The Region
-	must not be altered by the driver and will be deleted when the
-	function returns.
+	which are obscured rather than the areas visible. 
 
     </quote>
 
@@ -3516,11 +3695,10 @@ typedef struct {
 		&f.indent;RegionPtr clipBoxes, pointer data )&e.code;
     <quote><p>
 	  This indicates that the driver should take a subsection
-	  &s.code;vid_w&nbsp;&times;&nbsp;vid_h&e.code; at location
+	  &s.code;vid_w&e.code; by &s.code;vid_h&e.code; at location
 	  &s.code;(vid_x,vid_y)&e.code; from the video stream and direct
-	  it into the rectangle
-	  &s.code;rw_w&nbsp;&times;&nbsp;drw_h&e.code; at location
-	  &s.code;(drw_x,drw_y)&e.code; on the screen, scaling as
+	  it into the rectangle &s.code;drw_w&e.code; by &s.code;drw_h&e.code;
+	  at location &s.code;(drw_x,drw_y)&e.code; on the screen, scaling as
 	  necessary.  Due to the large variations in capabilities of
 	  the various hardware expected to be used with this extension,
 	  it is not expected that all hardware will be able to do this
@@ -3608,8 +3786,9 @@ typedef struct {
 	  encoding the particular port should be using (see the description
 	  of &s.code;XF86VideoEncodingRec&e.code; below).  If the
 	  requested encoding is unsupported, the driver should return
-	  &s.code;XvBadEncoding&e.code;.  &s.code;Success&e.code; should
-	  be returned otherwise.
+	  &s.code;XvBadEncoding&e.code;.  If the value lies outside the
+	  advertised range &s.code;BadValue&e.code; may be returned.
+	  &s.code;Success&e.code; should be returned otherwise.
 
     </quote>
 
@@ -3621,15 +3800,58 @@ typedef struct {
 	   &s.code;QueryBestSize&e.code; provides the client with a way
 	   to query what the destination dimensions would end up being
 	   if they were to request that an area
-	   &s.code;vid_w&nbsp;&times;&nbsp;vid_h&e.code; from the video
+	   &s.code;vid_w&e.code by &s.code;vid_h&e.code; from the video
 	   stream be scaled to rectangle of
-	   &s.code;drw_w&nbsp;&times;&nbsp;drw_h&e.code; on the screen.
+	   &s.code;drw_w&e.code; by &s.code;drw_h&e.code; on the screen.
 	   Since it is not expected that all hardware will be able to
 	   get the target dimensions exactly, it is important that the
 	   driver provide this function.  The returned dimensions must
 	   be less than or equal to the requested dimension.
 
     </quote>
+
+	&s.code;typedef  int (* PutImageFuncPtr)( ScrnInfoPtr pScrn, 
+		&f.indent;short src_x, short src_y, short drw_x, short drw_y,
+		&f.indent;short src_w, short src_h, short drw_w, short drw_h,
+		&f.indent;int image, char *buf, short width, short height,
+		&f.indent;Bool sync, RegionPtr clipBoxes, pointer data )&e.code;
+    <quote><p>
+	  This is similar to &s.code;PutStill&e.code; except that the
+	  source of the video is not a port but the data stored in a system 
+	  memory buffer at &s.code;buf&e.code;.  The data is in the format 
+	  indicated by the &s.code;image&e.code; descriptor and represents a 
+	  source of size &s.code;width&e.code; by &s.code;height&e.code;.
+	  If &s.code;sync&e.code; is TRUE the driver should not return
+	  from this function until it is through reading the data
+	  from &s.code;buf&e.code;.  Returning when &s.code;sync&e.code;
+	  is TRUE indicates that it is safe for the data at &s.code;buf&e.code;
+	  to be replaced, freed, or modified.
+	
+    </quote>
+
+	&s.code;typedef  int (* QueryImageAttributesFuncPtr)( ScrnInfoPtr pScrn,
+		&f.indent;int image, short *width, short *height,
+		&f.indent;int *pitches, int *offsets)&e.code;
+    <quote><p>
+	  This function is called to let the driver specify how data for
+	  a particular &s.code;image&e.code; of size &s.code;width&e.code;
+	  by &s.code;height&e.code; should be stored.  Sometimes only
+	  the size and corrected width and height are needed.  In that
+	  case &s.code;pitches&e.code; and &s.code;offsets&e.code; are
+	  NULL.  The size of the memory required for the image is returned
+	  by this function.  The &s.code;width&e.code; and 
+	  &s.code;height&e.code; of the requested image can be altered by
+	  the driver to reflect format limitations (such as component
+	  sampling periods that are larger than one).  If 
+	  &s.code;pitches&e.code; and &s.code;offsets&e.code; are not NULL,
+	  these will be arrays with as many elements in them as there
+	  are planes in the &s.code;image&e.code; format.  The driver
+	  should specify the pitch (in bytes) of each scanline in the
+	  particular plane as well as the offset to that plane (in bytes)
+	  from the begining of the image.
+	
+    </quote>
+
     </quote>
 
 The XF86VideoEncodingRec:
@@ -3641,8 +3863,8 @@ typedef struct {
 	unsigned short width, height;
 	XvRationalRec rate;
 } XF86VideoEncodingRec, *XF86VideoEncodingPtr;
-</verb>
 
+</verb>
    The &s.code;XF86VideoEncodingRec&e.code; specifies what encodings
    the adaptor can support.  Most of this data is just informational
    and for the client's benefit, and is what will be reported by
@@ -3671,32 +3893,159 @@ typedef struct {
 
 </quote>
 
-The XF86AttributeListRec:
+The XF86AttributeRec:
 
 <quote><p>
 <verb>
 typedef struct {
-	int   number;  
-	int   *flags;
-	char  **names;
+	int   flags;
+	int   min_value;
+	int   max_value;
+	char  *name;
 } XF86AttributeListRec, *XF86AttributeListPtr;
+
 </verb>
 
-   Each port will have one of these indicating the &s.code;number&e.code;
-   of attributes for that port, an array of names of the attributes and
-   an array of flags associated with each attribute.  Both arrays are
-   &s.code;number&e.code; in size.  Currently defined flags are
-   &s.code;XvGettable&e.code; and &s.code;XvSettable&e.code; which may
-   be OR'd together indicating that attribute is ``gettable'' or ``settable''
-   by the client.  Both arrays can be nulled if number is zero.  While
-   the Xv DDX copies most data from these structures and stores it
-   internally, including adaptor and encoding names, the attribute names
-   are not copied, but only their pointers.  Because of this, the strings
-   pointed to by &s.code;names[]&e.code; must exist as long as Xv is
-   initialized.
+   Each adaptor may have an array of these advertising the attributes
+   for its ports.  Currently defined flags are &s.code;XvGettable&e.code; 
+   and &s.code;XvSettable&e.code; which may be OR'd together indicating that 
+   attribute is ``gettable'' or ``settable'' by the client.  The 
+   &s.code;min&e.code; and &s.code;max&e.code; field specify the valid range 
+   for the value.  &s.code;Name&e.code; is a text string describing the
+   attribute by name.
 
 </quote>
 
+The XF86ImageRec:
+
+<quote><p>
+<verb>
+typedef struct {
+	int id;
+	int type;
+	int byte_order;
+	char guid[16];               
+	int bits_per_pixel;
+	int format;
+	int num_planes;
+
+	/* for RGB formats */
+	int depth;
+	unsigned int red_mask;       
+	unsigned int green_mask;   
+	unsigned int blue_mask;   
+
+	/* for YUV formats */
+	unsigned int y_sample_bits;
+	unsigned int u_sample_bits;
+	unsigned int v_sample_bits;   
+	unsigned int horz_y_period;
+	unsigned int horz_u_period;
+	unsigned int horz_v_period;
+	unsigned int vert_y_period;
+	unsigned int vert_u_period;
+	unsigned int vert_v_period;
+	char component_order[32];
+	int scanline_order;
+} XF86ImageRec, *XF86ImagePtr; 
+</verb>
+
+   XF86ImageRec describes how video source data is laid out in memory.
+   The fields are as follows:
+
+    &s.code;id&e.code;
+    <quote><p>
+	This is a unique descriptor for the format.  It is often good to
+        set this value to the FOURCC for the format when applicable. 
+    </quote>
+
+    &s.code;type&e.code;
+    <quote><p>
+	This is &s.code;XvRGB&e.code; or &s.code;XvYUV&e.code;. 
+    </quote>
+
+    &s.code;byte_order&e.code;
+    <quote><p>
+	This is &s.code;LSBFirst&e.code; or &s.code;MSBFirst&e.code;. 
+    </quote>
+
+    &s.code;guid&e.code;
+    <quote><p>
+	This is the Globally Unique IDentifier for the format.  When
+	not applicable, all characters should be NULL. 
+    </quote>
+
+    &s.code;bits_per_pixel&e.code;
+    <quote><p>
+	The number of bits taken up (but not necessarily used) by each
+	pixel.  Note that for some planar formats which have fractional
+	bits per pixel (such as IF09) this number may be rounded _down_.
+    </quote>
+
+    &s.code;format&e.code;
+    <quote><p>
+	This is &s.code;XvPlanar&e.code; or &s.code;XvPacked&e.code;. 
+    </quote>
+
+   &s.code;num_planes&e.code;
+    <quote><p>
+	The number of planes in planar formats.  This should be set to
+	one for packed formats.
+    </quote>
+
+   &s.code;depth&e.code;
+    <quote><p>
+	The significant bits per pixel in RGB formats (analgous to the
+	depth of a pixmap format).
+    </quote>
+
+   &s.code;red_mask&e.code;
+   &s.code;green_mask&e.code;
+   &s.code;blue_mask&e.code;
+    <quote><p>
+	The red, green and blue bitmasks for packed RGB formats.
+    </quote>
+
+   &s.code;y_sample_bits&e.code;
+   &s.code;u_sample_bits&e.code;
+   &s.code;v_sample_bits&e.code;
+    <quote><p>
+	The y, u and v sample sizes (in bits).
+    </quote>
+
+   &s.code;horz_y_period&e.code;
+   &s.code;horz_u_period&e.code;
+   &s.code;horz_v_period&e.code;
+    <quote><p>
+	The y, u and v sampling periods in the horizontal direction.
+    </quote>
+
+   &s.code;vert_y_period&e.code;
+   &s.code;vert_u_period&e.code;
+   &s.code;vert_v_period&e.code;
+    <quote><p>
+	The y, u and v sampling periods in the vertical direction.
+    </quote>
+
+   &s.code;component_order&e.code;
+    <quote><p>
+	Uppercase ascii characters representing the order that 
+	samples are stored within packed formats.  For planar formats
+	this represents the ordering of the planes.  Unused characters
+	in the 32 byte string should be set to NULL.
+    </quote>
+
+   &s.code;scanline_order&e.code;
+    <quote><p>
+	This is &s.code;XvTopToBottom&e.code; or &s.code;XvBottomToTop&e.code;. 
+    </quote>
+
+  Since some formats (particular some planar YUV formats) may not
+be completely defined by the parameters above, the guid, when
+available, should provide the most accurate description of the 
+format.
+
+</quote>
 
 <sect>The Loader
 <p>
@@ -4488,8 +4837,8 @@ strongly encouraged to improve the consistency of driver behaviour.
 <p>
 
   <quote><p>
-    &s.code;Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp, int fbbpp,
-			&f.indent;int depth24flags)&e.code;
+    &s.code;Bool xf86SetDepthBpp(ScrnInfoPtr scrp, int depth, int bpp,
+                        &f.indent;int fbbpp, int depth24flags)&e.code;
     <quote><p>
       This function sets the &s.code;depth&e.code;, &s.code;pixmapBPP&e.code; and &s.code;bitsPerPixel&e.code; fields
       of the &s.code;ScrnInfoRec&e.code;.  It also determines the defaults for display-wide
@@ -4845,11 +5194,21 @@ be catered for the by the helpers.
 		<quote>mode with closest matching clock</quote>
                 &s.code;LOOKUP_LIST_ORDER&e.code;
 		<quote>first usable mode in list</quote>
+
+		The following options can also be combined (OR'ed) with
+		one of the above:
+
                 &s.code;LOOKUP_CLKDIV2&e.code;
 		<quote>Allow halved clocks</quote>
+		&s.code;LOOKUP_OPTIONAL_TOLERANCES&e.code;
+		<quote>Allow missing horizontal sync and/or vertical refresh
+		ranges in the XF86Config Monitor section</quote>
 
-		&s.code;LOOKUP_CLKDIV2&e.code; can be combined (OR'ed)
-		with one of the others.
+		&s.code;LOOKUP_OPTIONAL_TOLERANCES&e.code; should only be
+		specified when the driver can ensure all modes it generates
+		can sync on, or at least not damage, the monitor or digital
+		flat panel.  Horizontal sync and/or vertical refresh ranges
+		specified by the user will still be honoured (and acted upon).
 
 	</quote>
 
@@ -4857,21 +5216,23 @@ be catered for the by the helpers.
       &s.code;ScrnInfoRec&e.code; are initialised prior to calling it:
 
         &s.code;clock[]&e.code;
-	<quote>List of discrete clocks (when non-programmable).</quote>
+	<quote>List of discrete clocks (when non-programmable)</quote>
         &s.code;numClocks&e.code;
-	<quote>Number of discrete clocks (when non-programmable).</quote>
+	<quote>Number of discrete clocks (when non-programmable)</quote>
         &s.code;progClock&e.code;
-	<quote>Whether the clock is programmable or not.</quote>
-        &s.code;formats&e.code;
-	<quote>pixmap formats for screen</quote>
-        &s.code;numFormats&e.code;
-	<quote>number of pixmap formats for screen</quote>
+	<quote>Whether the clock is programmable or not</quote>
+        &s.code;monitor&e.code;
+	<quote>Pointer to the applicable XF86Config monitor section</quote>
+        &s.code;fdFormat&e.code;
+	<quote>Format of the screen buffer</quote>
         &s.code;videoRam&e.code;
 	<quote>total video memory size (in bytes)</quote>
         &s.code;maxHValue&e.code;
 	<quote>Maximum horizontal timing value allowed</quote>
         &s.code;maxVValue&e.code;
 	<quote>Maximum vertical timing value allowed</quote>
+        &s.code;xInc&e.code;
+	<quote>Horizontal timing increment in pixels (defaults to 8)</quote>
 
       This function fills in the following &s.code;ScrnInfoRec&e.code;
       fields:
@@ -4922,15 +5283,21 @@ be catered for the by the helpers.
       the virtual width and height limits (if greater than zero).  For
       each mode removed an informational message is printed at verbosity
       level &s.code;2&e.code;.  If the mode pool ends up being empty,
-      an error message is printed, and the return value is
-      &s.code;-1&e.code;.
+      a warning message is printed, and the return value is
+      &s.code;0&e.code;.
 
-      The final stage is to lookup each mode, and fill in the remaining
+      The final stage is to lookup each mode name, and fill in the remaining
       parameters.  If an error condition is encountered, a message is
       printed, and the return value is &s.code;-1&e.code;.  Otherwise,
       the return value is the number of valid modes found
       (&s.code;0&e.code; if none are found).
 
+      Even if the supplied mode names include duplicates, no two names will
+      ever match the same mode.  Furthermore, if the supplied mode names do not
+      yield a valid mode (including the case where no names are passed at all),
+      the function will continue looking through the mode pool until it finds
+      a mode that survives all checks, or until the mode pool is exhausted.
+
       A message is only printed by this function when a fundamental
       problem is found.  It is intended that this function may be called
       more than once if there is more than one set of constraints that
@@ -4972,8 +5339,8 @@ be catered for the by the helpers.
 	</quote>
         &s.code;doubleScanAllowed&e.code;
 	<quote><p>
-		&s.code;TRUE&e.code; if doublescan is allowed for this
-		range
+		&s.code;TRUE&e.code; if doublescan or multiscan is allowed
+		for this range
 
 	</quote>
         &s.code;ClockMulFactor&nl;
@@ -5052,10 +5419,6 @@ be catered for the by the helpers.
       This function is normally called after calling
       &s.code;xf86PruneDriverModes()&e.code;.
 
-      NOTE: The &s.code;Crtc*&e.code; fields are not initialised anywhere
-      else, so the driver must either call this function or initialise
-      them itself.
-
     </quote>
 
     &s.code;void xf86PrintModes(ScrnInfoPtr scrp)&e.code;
@@ -5126,7 +5489,8 @@ use of some of these secondary mode helper functions.
     </quote>
 
     &s.code;ModeStatus xf86InitialCheckModeForDriver(ScrnInfoPtr scrp,
-		&f.indent;DisplayModePtr mode, int maxPitch,
+		&f.indent;DisplayModePtr mode, ClockRangePtr clockRanges,
+		&f.indent;LookupModeFlags strategy, int maxPitch,
 		&f.indent;int virtualX, int virtualY)&e.code;
     <quote><p>
       This function checks the passed mode against some basic driver
@@ -5134,9 +5498,10 @@ use of some of these secondary mode helper functions.
       &s.code;maxHValue&e.code; and &s.code;maxVValue&e.code; fields of
       the &s.code;ScrnInfoRec&e.code; are also used.  If the
       &s.code;ValidMode&e.code; field of the &s.code;ScrnInfoRec&e.code;
-      is set, that function is also called to check the mode.
+      is set, that function is also called to check the mode.  Next, the
+      mode is checked against the monitor's constraints.
 
-      If the mode is consistent with the constraints, the return value
+      If the mode is consistent with all constraints, the return value
       is &s.code;MODE_OK&e.code;.  Otherwise the return value indicates
       which constraint wasn't met.
 
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile b/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile
index c515a9007..4ffcaae1d 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile
@@ -3,14 +3,15 @@ XCOMM $XConsortium: Imakefile /main/16 1996/10/28 05:13:04 kaleb $
 
 
 
-XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile,v 3.45 1999/08/24 11:24:09 dawes Exp $
+XCOMM $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/Imakefile,v 3.49 1999/11/26 00:53:14 dawes Exp $
 
 #include <Server.tmpl>
 #include <lnxdoc.rules>
 
 SGMLDEPENDS = defs.ent
   INDEXLIST = README.sgml RELNOTES.sgml LICENSE.sgml DESIGN.sgml \
-	      mouse.sgml fonts.sgml isc.sgml \
+	      mouse.sgml fonts.sgml \
+	      isc.sgml NetBSD.sgml OpenBSD.sgml \
               ati.sgml chips.sgml DECtga.sgml s3virge.sgml SiS.sgml
 
 #if 0
@@ -53,6 +54,7 @@ LinuxDocReadmeTarget(cyrix)
 LinuxDocReadmeTarget(epson)
 LinuxDocReadmeTarget(fbdev)
 LinuxDocReadmeTarget(i740)
+LinuxDocReadmeTarget(r128)
 LinuxDocReadmeTarget(neomagic)
 LinuxDocReadmeTarget(rendition)
 LinuxDocReadmeTarget(s3virge)
@@ -93,3 +95,5 @@ index.sgml: $(INDEXLIST) index.pre index.post add.sh Imakefile $(SGMLDEPENDS)
 
 LinuxDocTarget(index)
 
+clean::
+	RemoveFile(index.sgml)
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml
index 155e41b02..348544ab3 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml
@@ -165,7 +165,7 @@ Mark Vojkovich, <it>mvojkovi@sdcc10.ucsd.edu</it>
 and:
 
 <itemize>
-<item>Andrew Vanderstock, <it>vanderaj@mail2.svhm.org.au</it>
+<item>Andrew van der Stock, <it>ajv@greebo.net</it>
 <item>Angsar Hockmann, <it>Ansgar.Hockmann@hrz.uni-dortmund.de</it>
 <item>Michael Will, <it>Michael.Will@student.uni-tuebingen.de</it>
 <item>Andrew Mileski, <it>aem@ott.hookup.net</it>
@@ -179,7 +179,7 @@ and:
 </itemize>
 
 <verb>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml,v 3.8 1999/08/23 06:38:47 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/MGA.sgml,v 3.9 1999/11/19 13:54:27 hohndel Exp $
 </verb>
 
 </article>
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml
index b2438032d..94d44d092 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml
@@ -1,13 +1,15 @@
-<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
 
 <article>
-<title>README for XFree86 on NetBSD
+<title>README for XFree86 &relvers; on NetBSD
 <author>Rich  Murphey,
 David Dawes,
 Marc  Wandschneider,
 Mark  Weaver,
 Matthieu Herrb
-<Date>Last modified on: 25 June 1999
+<Date>Last modified on: 13 November 1999
 
 <toc>
 
@@ -15,7 +17,7 @@ Matthieu Herrb
 <sect>What and Where is XFree86?
 
 <p>
-XFree86 is a port of X11R6.3 that supports several versions of
+XFree86 is a port of X11R6.4 that supports several versions of
 Intel-based Unix.  It is derived from X386 1.2, which was the X server
 distributed with X11R5.  This release consists of many new features
 and performance improvements as well as many bug fixes.  The release
@@ -29,6 +31,7 @@ The sources for XFree86 are available by anonymous ftp from:
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/current"
 url="ftp://ftp.XFree86.org/pub/XFree86/current">
 
+<!--
 Binaries for NetBSD 1.2 are available from:
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.2"
 url="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.2">
@@ -36,11 +39,13 @@ url="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.2">
 Binaries for NetBSD 1.4 and later are available from:
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.4"
 url="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/NetBSD-1.4">
+-->
 
 A list of mirror sites is provided by
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/MIRRORS"
 url="ftp://ftp.XFree86.org/pub/XFree86/MIRRORS">
 
+<!--
 <p>
 Other NetBSD versions:
 
@@ -52,6 +57,8 @@ If you don't upgrade, you'll have to build XFree86 from the sources.
 XFree86 should compile cleanly under earlier versions of
 NetBSD, although this has not been tested.
 
+-->
+
 XFree86 also builds on NetBSD/sparc. See section
 <ref id="sparc" name="Building on other architectures"> for details.
 
@@ -64,7 +71,7 @@ XFree86 also supports NetBSD on PC98 machines.
 <sect>Bug Reports for This Document
 
 <p>
-Send email to <em/matthieu@laas.fr/ (Matthieu Herrb) or
+Send email to <em/herrb@XFree86.Org/ (Matthieu Herrb) or
 <em/XFree86@XFree86.org/ if you have comments or suggestions about
 this file and we'll revise it.
 
@@ -72,15 +79,15 @@ this file and we'll revise it.
 
 <p>
 <itemize>
-<item>The maximum number of open connections in the server has been
-raised to 128,
-<item>support for the <bf/wsmouse/ mouse protocol included in  NetBSD 1.4 has
-been added. 
+<item>Support for <em>silken mouse</em> with the wsmouse protocol has
+been added.
+<item>A new version of the XFree86 Aperture driver which provides MTRR 
+support is included.
 </itemize>
 
 <p>
 See the <htmlurl url="RELNOTES.html" name="Release Notes"> for
-non-OS dependent new features in XFree86 3.3.4.
+non-OS dependent new features in XFree86 3.9.17.
 
 <sect>Installing the Binaries
 
@@ -97,9 +104,11 @@ monitor,
 video card and mouse you have.  You <em/must/ create it to tell the
 server what specific hardware you have.
 <p>
+<!--
 The easiest way to create this file is to run the <bf/XF86Setup/
 utility as root. Refer to <htmlurl url="QuickStart.html"
 name="QuickStart.doc"> for details about its use.
+-->
 <p>
 You'll need info on your hardware:
 <itemize>
@@ -136,7 +145,7 @@ Only standard PS/2 mice are supported by this driver. Newest PS/2
 mice that send more than three bytes at a time (especially
 Intellimouse, or MouseMan+ with a ``3D'' roller) are not supported yet. 
 <p>
-XFree86 3.3.4 also has support for the mouse driver included in
+XFree86 3.9.17 also has support for the mouse driver included in
 the new <bf/wscons/ console driver introduced by NetBSD 1.4. Specify
 ``<tt/wsmouse/'' as the protocol and ``<tt>/dev/wsmouse0</tt>'' as the 
 device in <tt>/etc/XF86Config</tt> if you're using NetBSD 1.4 with
@@ -145,56 +154,10 @@ wscons.
 See <htmlurl url="mouse.html" name="README.mouse">  for general
 instruction on mouse configuration in XFree86.
 
-<sect1>Other input devices
-<p>
-XFree86  supports the dynamic loading of drivers for external
-input devices using the <tt/XInput/ extension. Currently supported
-devices are:
-<itemize>
-<item>Joystick (<tt/xf86Jstk.so/)
-<item>Wacom tablets (Wacom IV protocol only, <tt/xf86Wacom.so/)
-<item>SummaSketch tablets (<tt/xf86Summa.so/)
-<item>Elographics touchscreen (<tt/xf86Elo.so/)
-</itemize>
-
-To use a specific device, add the line
-<tscreen>
-<tt/load/ <tt/"/<em/module/<tt/"/
-</tscreen>
-in the <bf/Module/ section of <tt/XF86Config/, where <em/module/ is
-the name of the <tt/.so/ file corresponding to your device.
-You also need to set up a <bf/XInput/ section in <tt/XF86Config/. 
-Refer to the <em>XF86Config(5)</em> man page for detailed
-configuration instructions.
-<p>
-You can then change the device used to drive the X pointer with the
-<em/xsetpointer(1)/ command.
-<p>
-For joystick support, you'll need to install the joystick device
-driver in the kernel. It is included in NetBSD 1.2. See
-<em/joy(4)/ for details.
-
-<sect1>Configuring PEX and XIE extensions
-<p>
-The PEX and XIE extensions are  supported as external modules.
-If you want to have access to these extensions, add the following
-lines to the <bf/Module/ section of <tt/XF86Config/:
-<tscreen><verb>
-   load    "pex5.so"
-   load    "xie.so"
-</verb></tscreen>
-
 
 <sect>Running X
 
 <p>
-8mb of memory is a recommended minimum for running X.  The server,
-window manager and an xterm take about 4 Mb of memory themselves.  On
-a 4Mb system that would leave nothing left over for other applications
-like gcc that expect a few meg free.  X will work with 4Mb of memory,
-but in practice compilation while running X can take 5 or 10 times as
-long due to constant paging.
-
 The easiest way for new users to start X windows is to type: 
 <tscreen><verb>
 startx >& startx.log
@@ -313,72 +276,54 @@ informations on how to configure wscons into the kernel.
 
 <sect1>Aperture Driver
 <p>
-By default NetBSD 0.9C and higher include the BSD 4.4 kernel security
+By default NetBSD include the BSD 4.4 kernel security
 feature that disable access to the <tt>/dev/mem</tt> device when in
 multi-users mode. But XFree86 servers can take advantage (or require)
 linear access to the display memory.
 
-Moset recent accelerated servers require linear memory access, some
+Most recent accelerated servers require linear memory access, some
 other can take advantage of it, but do not require it.
 
 There are two ways to allow XFree86 to access linear memory:
 
 The first way is to disable the kernel security feature by adding
-`option INSECURE' in the kernel configuration file and build a new
+``<tt/option INSECURE/'' in the kernel configuration file and build a new
 kernel.
 
 
-The second way is to install the aperture driver:
-You can get the aperture driver sources from 
-<htmlurl url="ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/apNetBSD.shar" 
-name="ftp://ftp.netbsd.org/pub/NetBSD/arch/i386/apNetBSD.shar">.
-
-How to activate it is highly dependent from your exact operating
-system version:
-<itemize>
-<item> NetBSD 1.0, 1.1, 1.2, 1.2.1:
-<p>
-Add the following lines to the end of <tt>/etc/rc.local</tt>:
+The second way is to install the aperture driver, included in source form in
+<tt>xc/programs/Xserver/hw/xfree86/etc/apNetBSD-2.shar</tt> in the
+XFree86 3.9.17 source distribution. Unpack it in a new directory of your 
+choice by running:
 <tscreen><verb>
- KERNDIR=/usr/X11R6/lib/X11/kernel
- if [ -f ${KERNDIR}/ap.o ]; then
-   modload -o ${KERNDIR}/ap -e ap -p ${KERNDIR}/apinstall ${KERNDIR}/ap.o
- fi
+  sh apNetBSD-2.shar
 </verb></tscreen>
 
-<item> NetBSD 1.2D and later
-<p>
-Add the following line to  <tt>/etc/lkm.conf</tt>:
-<tscreen><verb>
-/usr/X11R6/lib/X11/kernel/ap.o  -  ap /usr/X11R6/lib/X11/kernel/apinstall - 
-</verb></tscreen> 
-
-<item> NetBSD 1.2G, 1.3 and later
-<p>
-The <tt>lkm.conf</tt> format changed in 1.2G. 
-Add the following line to  <tt>/etc/lkm.conf</tt>:
+Then run ``<tt>make build</tt>'' as root to install it. To enable it, 
+add the following line to  <tt>/etc/lkm.conf</tt>:
 <tscreen><verb>
-/usr/X11R6/lib/X11/kernel/ap.o  -  ap /usr/X11R6/lib/X11/kernel/apinstall - -AFTERMOUNT
+/usr/X11R6/lib/X11/kernel/ap.o  -  - /usr/X11R6/lib/X11/kernel/apinstall - -
 </verb></tscreen> 
-</itemize>
+and set ``<tt/lkm=YES/'' in <tt>/etc/rc.conf</tt>
 
 Reboot your system. XFree86 will auto-detect the aperture
 driver if available.
 
-<bf/Warning:/ if you boot another kernel than <tt>/netbsd</tt> or
-<tt>/bsd</tt>,
+<bf/Warning 1:/ if you boot another kernel than <tt>/netbsd</tt>,
 loadable kernel modules can crash your system. Always boot in
 single user mode when you want to run another kernel.
 
 <p>
-<quote>
-<bf/Caveat:/ the  aperture driver only allows one access at a time
+<bf/Warning 2:/ the  aperture driver only allows one access at a time
 (so that the system is in the same security state once X is
 launched). This means that if you run multiple servers on multiples
 VT, only the first one will have linear memory access.
-Use 'option INSECURE' if you need more that one X server at a time.
-</quote>
+Use ``option INSECURE'' if you need more that one X server at a time.
 
+<p>
+Together with XFree86 3.9.17, a new version of the aperture driver
+is provided, which also supports MTRR write combining on Pentiums II
+and AMD K6 class processors. 
 
 <sect1>MIT-SHM
 <p>
@@ -401,12 +346,6 @@ extension.
 <sect> Rebuilding the XFree86 Distribution
 
 <p>
-The server link kit allow you to rebuild just the X server with a
-minimum amount of disk space.  Just unpack it, make the appropriate
-changes to the <tt/xf86site.def/, type ``<tt>./mkmf</tt>'' and
-``<tt/make/'' to link the server.  See <tt>/usr/X11R6/lib/Server/README</tt>
-for more info.
-
 See <htmlurl url="INSTALL.html" name="INSTALL"> for instructions on
 unbundling and building the source distribution.
 
@@ -414,8 +353,11 @@ You should configure the distribution by editing
 <tt>xc/config/cf/host.def</tt>  before compiling.  To compile the
 sources, invoke ``<tt/make World/'' in the xc directory.
 
-<sect1>Console drivers<label id="console-drivers">
+To build the XFree86 server with the Aperture driver enabled, you
+should unpack <tt>apNetBSD-2.shar</tt> and install it before making World in
+the XFree86 tree. 
 
+<sect1>Console drivers<label id="console-drivers">
 
 <p>
 XFree86 has a configuration option to select the console
@@ -429,23 +371,10 @@ drivers to use in <tt/xf86site.def/:
 <tscreen><verb>
  #define XFree86ConsoleDefines -DPCVT_SUPPORT
 </verb></tscreen>
-<item>if you're using syscons put:
-<tscreen><verb>
- #define XFree86ConsoleDefines -DSYSCONS_SUPPORT
-</verb></tscreen>
-<item>if you're running codrv put:
-<tscreen><verb>
- #define XFree86ConsoleDefines -DCODRV_SUPPORT
-</verb></tscreen>
 </itemize>
 If you don't define <bf/XFree86ConsoleDefines/ in <tt/xf86site.def/ the
 pccons and pcvt drivers will be supported by default.
 
-<p>
-Syscons and codrv are not bundled with NetBSD. They are
-available by anonymous FTP from a number of sites. They are not
-supported by the XFree86 binary distribution anymore. 
-
 <sect1>pcvt_ioctl.h file:
 
 <p>
@@ -465,35 +394,6 @@ can remove -DPCVT_SUPPORT from <bf/XFree86ConsoleDefines/ in
 <tt/xf86site.def/ too.
 
 
-<sect1>console.h and ioctl_pc.h files:
-
-<p>
-If you want to build a server supporting codrv and you
-don't already have the corresponding header file 
-<tt/ioctl_pc.h/ installed in <tt>/usr/include/machine</tt>, then
-install the copy that is supplied in
-<tt>xc/programs/Xserver/hw/xfree86/etc</tt>.  If you run
-NetBSD-current you probably want to install it in
-<tt>/usr/src/sys/arch/i386/include</tt> too, so that it get
-reinstalled each time you run <tt/make includes/.
-
-If you have installed the  codrv console driver, this
-file should be taken from your installed version of the driver.
-
-The <tt/console.h/ file for syscons isn't distributed with XFree86
-anymore. You should get it from the syscons distribution.
-
-<sect1>Support for shared libs under NetBSD 1.0 and later
-
-<p>
-By default XFree86 builds for NetBSD with shared libraries 
-support. If you're building on 0.9 or don't want shared libraries 
-add the following line to <tt/host.def/:
-
-<tscreen>	
- #define BuildBsdSharedLibs 	NO
-</tscreen>
-
 <sect1>Building on other architectures<label id="sparc">
 
 <p>
@@ -514,7 +414,7 @@ url="INSTALL.html">.
 
 Problems with this port should be reported to the
 <em/port-sparc@NetBSD.Org/ mailing list or directly to me
-<em/matthieu@laas.fr/ rather than to the xfree86 mailing list. 
+<em/herrb@XFree86.Org/ rather than to the xfree86 mailing list. 
 
 <p> 
 Note that the NetBSD project has now its own source tree, based on the
@@ -538,9 +438,8 @@ To avoid the ``Virtual memory exhausted'' message from cc while
 compiling, increase the data and stack size limits (in csh type ``<tt/limit
 datasize 32M/'' and ``<tt/limit stacksize 16M/'').
 
-Note: Starting with XFree86 2.1 and NetBSD 0.9A, the symbol
-<bf/__386BSD__/ no longer gets defined either by the compiler or via the
-X config files for *BSD systems.  When porting clients to *BSD
+
+When porting clients to *BSD
 systems, make use of the symbol <bf/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
@@ -559,7 +458,7 @@ and later.  This should be used to protect the inclusion of
 For code that really is specific to a particular i386 BSD port, use
 <bf/__FreeBSD__/ for FreeBSD, <bf/__NetBSD__/ for NetBSD,
 <bf/__OpenBSD__/ for OpenBSD,
-<bf/__386BSD__/ for 386BSD, and <bf/__bsdi__/ for BSD/386.
+and <bf/__bsdi__/ for BSD/386.
 
 Another note: If you get the message:
 
@@ -576,19 +475,13 @@ Imakefile or Makefile and relink.
 
 <sect> Thanks
 <p>
-Many thanks to:
-<itemize>
-<item><bf/Pace Willison/ for providing the initial port to 386BSD.
-<item><bf/Amancio Hasty/ for fixing cursor restoration, mouse bugs
-and many others. 
-<item><bf/Christoph Robitschko/ for fixing <tt/com.c/ and thus select().
-<item><bf/Nate Williams/ for the patchkit support for X.
-<item><bf/Rod Grimes/ and <bf/Jack Velte/ of Walnut Creek Cdrom for use
-  of their machines in preparing the FreeBSD binary release.
-</itemize>
+Many thanks to all people who contributed to make XFree86 work on
+*BSD, in particular, <bf/David Dawes/,
+<bf/Pace Willison/, <bf/Amancio Hasty/, <bf/Christoph Robitschko/,
+<bf/Nate Williams/, <bf/Rod Grimes/, <bf/Jack Velte/ and <bf/Michael Smith/.
 
 <verb>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.49 1999/08/23 06:38:48 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/NetBSD.sgml,v 3.51 1999/11/26 00:51:51 dawes Exp $
 
 
 
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml
index b7aba4214..cf995186b 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml
@@ -1,10 +1,12 @@
-<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN" [
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
 
 <article>
-<title>README for XFree86 on OpenBSD
+<title>README for XFree86 &relvers; on OpenBSD
 <author>
 Matthieu Herrb
-<Date>Last modified on: 25 June 1999
+<Date>Last modified on: 13 November 1999
 
 <toc>
 
@@ -12,7 +14,7 @@ Matthieu Herrb
 <sect>What and Where is XFree86?
 
 <p>
-XFree86 is a port of X11R6.3 that supports several versions of
+XFree86 is a port of X11R6.4 that supports several versions of
 Intel-based Unix.  It is derived from X386 1.2, which was the X server
 distributed with X11R5.  This release consists of many new features
 and performance improvements as well as many bug fixes.  The release
@@ -26,10 +28,12 @@ The sources for XFree86 are available by anonymous ftp from:
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/current"
 url="ftp://ftp.XFree86.org/pub/XFree86/current">
 
+<!--
 Binaries for OpenBSD 2.5 and later are available from:
 
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/OpenBSD"
 url="ftp://ftp.XFree86.org/pub/XFree86/current/binaries/OpenBSD">
+-->
 
 A list of mirror sites is provided by
 <htmlurl name="ftp://ftp.XFree86.org/pub/XFree86/MIRRORS"
@@ -51,19 +55,21 @@ this file and we'll revise it.
 <sect>New features in this release
 <p>
 <itemize>
-<item>The maximum number of open connections in the server has been
-raised to 128,
-<item>the <tt>resize</tt> utility was fixed.
+<item><em>Silken mouse</em> is supported for serial mices, and, under
+post 2.6 OpenBSD-current for PS/2 mices.
+<item>MTRR Write Combining is enabled uner post 2.6 OpenBSD-current. 
 </itemize>
 <p>
 See the <htmlurl url="RELNOTES.html" name="Release Notes"> for
-non-OS dependent new features in XFree86 3.3.4.
+non-OS dependent new features in XFree86 3.9.17
 
+<!--
 <sect>Installing the Binaries
 
 <p>
 Refer to section 5 of the <htmlurl url="RELNOTES.html" name="Release
 Notes">  for detailed installation instructions.
+-->
 
 <sect>Configuring X for Your Hardware
 
@@ -73,10 +79,12 @@ monitor,
 video card and mouse you have.  You <em/must/ create it to tell the
 server what specific hardware you have.
 <p>
+<!--
 The easiest way to create this file is to run the <bf/XF86Setup/
 utility as root. Refer to <htmlurl url="QuickStart.html"
 name="QuickStart.doc"> for details about its use.
 <p>
+-->
 You'll need info on your hardware:
 <itemize>
 <item>Your mouse type, baud rate and its /dev entry.
@@ -121,54 +129,10 @@ intellimouse, or mouseman+ with a "3D" roller).
 See <htmlurl url="mouse.html" name="README.mouse">  for general
 instruction on mouse configuration in XFree86.
 
-<sect1>Other input devices
-<p>
-XFree86  supports the dynamic loading of drivers for external
-input devices using the <tt/XInput/ extension. Currently supported
-devices are:
-<itemize>
-<item>Joystick (<tt/xf86Jstk.so/)
-<item>Wacom tablets (Wacom IV protocol only, <tt/xf86Wacom.so/)
-<item>SummaSketch tablets (<tt/xf86Summa.so/)
-<item>Elographics touchscreen (<tt/xf86Elo.so/)
-</itemize>
-
-To use a specific device, add the line
-<tscreen>
-<tt/load/ <tt/"/<em/module/<tt/"/
-</tscreen>
-in the <bf/Module/ section of <tt/XF86Config/, where <em/module/ is
-the name of the <tt/.so/ file corresponding to your device.
-You also need to set up a <bf/XInput/ section in <tt/XF86Config/. 
-Refer to the <em>XF86Config(5)</em> man page for detailed
-configuration instructions.
-<p>
-You can then change the device used to drive the X pointer with the
-<em/xsetpointer(1)/ command.
-<p>
-For joystick support, you'll need to enable the joystick device
-driver in the kernel.  See <em/joy(4)/ for details.
-
-<sect1>Configuring PEX and XIE extensions
-<p>
-The PEX and XIE extensions are  supported as external modules.
-If you want to have access to these extensions, add the following
-lines to the <bf/Module/ section of <tt/XF86Config/:
-<tscreen><verb>
-   load    "pex5.so"
-   load    "xie.so"
-</verb></tscreen>
 
 <sect>Running X
 
 <p>
-8mb of memory is a recommended minimum for running X.  The server,
-window manager and an xterm take about 4 Mb of memory themselves.  On
-a 4Mb system that would leave nothing left over for other applications
-like gcc that expect a few meg free.  X will work with 4Mb of memory,
-but in practice compilation while running X can take 5 or 10 times as
-long due to constant paging.
-
 
 <sect1>Starting xdm, the display manager
 
@@ -240,54 +204,21 @@ accelerated servers can take advantage of it, but do not require it.
 Some drivers in the SVGA server require linear memory access too,
 notably the Matrox driver.
 
-The preferred  way to allow XFree86 to access linear memory is to use
-the aperture driver 
-
-Ths step is highly dependent from your exact operating
-system version:
-<itemize>
-<item> OpenBSD 2.0
-    
-Use the aperture driver from /usr/lkm: 
-    
-add the following lines to the end of <tt>/etc/rc.local</tt>:
-<tscreen><verb>
- KERNDIR=/usr/lkm
- if [ -f ${KERNDIR}/ap.o ]; then
-   modload -o ${KERNDIR}/ap -e ap -p \
-   ${KERNDIR}/apinstall ${KERNDIR}/ap.o
- fi
-</verb></tscreen>
-
-<item> OpenBSD 2.1, 2.2
-    
-Uncomment the lines loading the aperture driver from
-<tt>/etc/rc.securelevel</tt> 
-
-<item> OpenBSD 2.3
+OpenBSD now requires the aperture driver to be enabled for all X
+servers, because the aperture driver also controls access to the
+I/O ports of the video boards.
      
 The aperture driver is part of the kernel.  Add 'option APERTURE' to
 your kernel configuration file, build and install the new kernel and
 run <tt>./MAKEDEV std</tt> in <tt>/dev</tt>. Edit
 <tt>/etc/sysctl.conf</tt> to set the variable
 <bf>machdep.allowaperture</bf> to 1.
-
-<item> OpenBSD 2.4 and later
-
-OpenBSD now requires the aperture driver to be enabled for all X
-servers, because the aperture driver also controls access to the
-I/O ports of the video boards.
-
-</itemize>
-
-After doing that, reboot your system. XFree86 will auto-detect the
-aperture driver if available.
-
 <p>
-<bf/Warning:/ if you boot another kernel than <tt>/bsd</tt>,
-loadable kernel modules can crash your system. Always boot in
-single user mode when you want to run another kernel.
-
+Another (less recommended) way to enable linear memory access is to
+disable the kernel security feature by adding ``option INSECURE'' in
+your kernel configuration file and build a new kernel.  In OpenBSD 2.2
+and later, you will also need to comment out the line initializing
+<tt/securelevel/ to 1 in <tt>/etc/rc.securelevel</tt>.
 <p>
 <quote>
 <bf/Caveat:/ the aperture driver only allows one access at a time
@@ -298,12 +229,6 @@ INSECURE' if you need more that one X server at a time.
 </quote>
 
 
-Another (less recommended) way to enable linear memory access is to
-disable the kernel security feature by adding ``option INSECURE'' in
-your kernel configuration file and build a new kernel.  In OpenBSD 2.2
-and later, you will also need to comment out the line initializing
-<tt/securelevel/ to 1 in <tt>/etc/rc.securelevel</tt>.
-
 <sect1>MIT-SHM
 <p>
 OpenBSD supports System V shared memory. If XFree86 
@@ -325,7 +250,7 @@ to your kernel config file.
 <sect> Rebuilding the XFree86 Distribution
 
 <p>
-The server link kit allow you to rebuild just the X server with a
+The server developper's kit allow you to rebuild just the X server with a
 minimum amount of disk space.  Just unpack it, make the appropriate
 changes to the <tt/xf86site.def/, type ``<tt>./mkmf</tt>'' and
 ``<tt/make/'' to link the server.  See <tt>/usr/X11R6/lib/Server/README</tt>
@@ -363,6 +288,7 @@ pccons and pcvt drivers will be supported.
 <p>
 XFree86 also compiles on other OpenBSD architectures. 
 
+<!--
 The XFree86 servers can also been built on OpenBSD/mips. The S3 server
 has been tested on an Acer Mips system with a S3/928 board. Contact
 Per Fogelstrom (pefo@OpenBSD.org) for details.
@@ -375,6 +301,7 @@ the sparc and the sun3.
 The client side of XFree86 also builds on the alpha, pmax, amiga,
 mac68k and mvme68k architectures.
 
+-->
 Problems with this port should be reported directly to the OpenBSD 
 mailing lists rather than to the xfree86 mailing list. 
 
@@ -397,9 +324,15 @@ necessary and type ``<tt/make/''.  Whenever you install additional man
 pages you should update <tt/whatis.db/ by running ``<tt>makewhatis
 /usr/X11R6/man</tt>''.
 
+<sect> Thanks
+<p>
+Many thanks to all people who contributed to make XFree86 work on
+*BSD, in particular, <bf/David Dawes/,
+<bf/Pace Willison/, <bf/Amancio Hasty/, <bf/Christoph Robitschko/,
+<bf/Nate Williams/, <bf/Rod Grimes/, <bf/Jack Velte/ and <bf/Michael Smith/.
 
 <verb>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.3 1999/08/23 06:38:50 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OpenBSD.sgml,v 1.5 1999/11/26 00:51:51 dawes Exp $
 
 
 
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml
index 0c40d9fcf..b8fec4b68 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml
@@ -9,7 +9,7 @@
 <date>31 August 1999
 
 <ident>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.18 1999/08/31 08:39:09 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/RELNOTES.sgml,v 1.21 2000/01/03 15:19:08 robin Exp $
 </ident>
 
 <abstract>
@@ -31,6 +31,42 @@ source tree.  The sections that follow this one have details of features
 that are new to the pre-4.0 snapshot series.
 
 <itemize>
+  <item>The 3dfx driver is now supported by the DRI.
+  <item>Tiny-X for the Itsy has been added.
+  <item>Significant font and font server enhancements.
+  <item>New driver for ATI Rage 128.  The driver is called "r128".
+  <item>Xterm enhancements and fixes.
+  <item>DPS support hooks have been added.
+       Display Postscript support is being maintained outside of the
+       server tree due to licensing issues.  A web page for DPS resources
+       under XFree86 will be available shortly.
+  <item>DRI enhancements including Mesa update to version 3.2, full support
+     and fifo code for 3dfx hardware, and device driver updates for
+     Linux 2.3 kernels.
+  <item>Significant enhancements to Xv including support for XvImages
+	(YUV XImages).
+  <item>Add initial VESA VBE support including initialization and DDC.
+  <item>Several PCI enhancements.
+  <item>"SilkenMouse" (asynchronous pointer handling) for smoother mouse movement.
+  <item>Add GeForce/Quadro support to the NVIDIA driver.
+  <item>Int10 "soft-booting" support for Linux.
+  <item>Resource allocation infrastructure added.
+  <item>Syntax of the layout section has changed to make multi-head configuration easier.
+  <item>Some Xinerama bug fixes.
+  <item>The DGA 2.0 interface is mostly finalized and includes some preliminary documentation.
+  <item>ViRGE MX Melco BIOS support has been added.
+  <item>Keyboard AutoRepeat now works correctly on Linux.  This means
+     that the AutoRepeat keyword in XF86Config is now obeyed; you may be
+     more comfortable using "250 30" rather than the default setting of
+     "500 5".
+
+
+</itemize>
+
+<sect>Summary of new features in 3.9.16 compared with 3.9.15.
+<p>
+
+<itemize>
   <item>The "apm" driver has been updated.
 	See the <ref id="apm" name="APM section"> below.
   <item>A driver for NVIDIA chipsets is now included.  The driver is called
@@ -214,9 +250,17 @@ Section "InputDevice"
     Driver      "mouse"
     Option      "Protocol"   "PS/2"
     Option      "Device"     "/dev/mouse"
+    SampleRate  80
 EndSection
 </verb></quote>
 
+     Note: Additional sample rates have been added for some mice.
+           Matching the mouse sampling rate with the vertical refresh
+           rate can yield very noticeable improvements in smoothness of
+           pointer event driven operations such as window moves and
+           scrolling.
+
+
   <item>The Monitor section is mostly unchanged.  The main difference is
 	that a set of VESA modes is defined internally in the server,
 	and so for most monitors, it isn't necessary to specify any modes
@@ -258,7 +302,7 @@ EndSection
 Section "ServerLayout"
     Identifier  "Layout 1"
     Screen      "MGA 1"
-    Screen      "MGA 2"
+    Screen      "MGA 2" RightOf "MGA 1"
     InputDevice "Keyboard 1" "CoreKeyboard"
     InputDevice "Mouse 1"    "CorePointer"
     InputDevice "Mouse 2"    "SendCoreEvents"
@@ -266,6 +310,10 @@ Section "ServerLayout"
 EndSection
 </verb></quote>
 
+     See the document xc/programs/Xserver/hw/xfree86/doc/DESIGN for a
+     more detailed explanation of the new ServerLayout section syntax.
+
+
 </itemize>
 
 The config file search patch has been extended, with the directories
@@ -461,9 +509,6 @@ we expect it to be improved further in future snapshots.
 
 Known problems:
 <itemize>
-  <item>The Xinerama layout doesn't match the layout specified in the
-	config file's ServerLayout section.
-
   <item>It appears that there are still some bugs that cause unexpected
 	behaviour from time to time.
 
@@ -483,10 +528,11 @@ Known problems:
 <sect1>DGA version 2
 <p>
 
-The DGA extension has been reworked.  The version present in this snapshot
-is preliminary, not documented, not implemented by many drivers, and
-subject to further change without notice.  Compatibility with version 1.0
-is provided.
+DGA 2.0 is nearly completed but still not implemented by all drivers.
+Preliminary documentation for the client libraries can be found in the
+xc/programs/Xserver/hw/xfree86/DGA document.  Some degree of backwards
+compatibility with version 1.0 is provided.
+
 
 <sect1>DDC
 <p>
@@ -496,8 +542,7 @@ monitor to tell the video card (or on some cases the computer
 directly) about itself; particularly the supported screen resolutions
 and refresh rates.
 
-Partial or complete DDC support is available in the following hardware modules
-(this list needs to be verified):
+Partial or complete DDC support is available in the following hardware modules:
 <itemize>
   <item>APM
   <item>Chips
@@ -559,10 +604,19 @@ highly optimized path for sending 3D data directly to the graphics
 hardware.  This release <url name="demonstrates a sample implementation
 of direct rendering" url="http://www.precisioninsight.com/demo.html">
 by providing a single path of 3D hardware accelerated rendering for
-the GMX2000 graphics card.  Future releases will support much broader
-implementations of hardware accelerated direct rendering on a wide
-range of 3D capable graphics devices.
+the GMX2000 and 3dfx voodoo graphics cards.  Future releases will support
+much broader implementations of hardware accelerated direct rendering on
+a wide range of 3D capable graphics devices.
 
+<sect1>X-Video Extension (Xv)
+<p>
+
+An XvQueryPortAttributes function has been added as well as
+support for XvImages.  XvImages are XImages in alternate color spaces 
+such as YUV and can be passed to the server through shared memory
+segments.  This allows clients to display YUV data with high quality
+hardware scaling and filtering.   XvImages are only supported
+by the Matrox G200/G400 cards at the moment.
 
 <sect1>Other extensions
 <p>
@@ -600,6 +654,7 @@ XFree86 &relvers; includes the following drivers:
    <tabrow><tt>mga</tt><colsep>Matrox</tabrow>
    <tabrow><tt>neomagic</tt><colsep>NeoMagic</tabrow>
    <tabrow><tt>nv</tt><colsep>NVIDIA</tabrow>
+   <tabrow><tt>r128</tt><colsep>ATI Rage 128</tabrow>
    <tabrow><tt>rendition</tt><colsep>Rendition</tabrow>
    <tabrow><tt>s3virge</tt><colsep>S3 ViRGE</tabrow>
    <tabrow><tt>sis</tt><colsep>SiS</tabrow>
@@ -650,7 +705,6 @@ Outstanding items not implemented or fully tested:
 
 <itemize>
   <item>DGA support is implemented, but preliminary and untested.
-  <item>ViRGE MX Melco BIOS support has not been ported yet.
 </itemize>
 
 <sect2>TGA
@@ -677,13 +731,10 @@ By default, the color key for the overlays is 255, but this can be
 changed with the <tt>"ColorKey"</tt> option to work around problems in
 specific programs.  Valid values for the key are 2-255.
 
-Option <tt>"OverclockMem"</tt> will raise the memory clock on the G200.
-Matrox doesn't recommend deviating from the BIOS defaults but we find
-that some hardware shows static during graphics operations in high
-resolutions/depths when run at the regular clocks so this option is
-needed for some cards (it also improves performance).  Beware, some
-hardware experiences difficultly restoring the console when this option
-is used.
+This release contains performance enhancements for the G400 and particularly
+for the G400 MAX.  It also includes XvImage support for G200/G400 chips and
+improved memory autodetection support.
+
 
 Further information can be found in the <tt>mga</tt> man page.
 
@@ -694,6 +745,38 @@ Information about the ATI driver can be found in <url name="README.ati"
 url="ati.html">.  The current version is not accelerated.  Acceleration
 support is planned for a future snapshot.
 
+<sect2>NVIDIA
+<p>
+
+The "nv" driver supports all Riva TNT accelerators as well as the  
+new GeForce and Quadro accelerators.  3.9.17 adds DGA 2.0 support
+and performance improvements as well as resolving some rendering
+correctness issues.
+
+Further information can be found in the nv man page.   
+
+<sect2>Glide
+<p>
+This driver is for Voodoo 1 and Voodoo 2 boards. It runs X on top of
+the 3DFX Glide API (where this is available, like for Linux). You need
+to have Glide 2.x installed before you can run this driver. This
+driver uses no hardware acceleration (since there is no 2D
+acceleration in these boards) but is rather quick anyway since the CPU
+renders to local RAM which is then copied block-wise to the
+board. Unfortunately the Voodoo 1/2 boards are rather limited in
+resolution. The Voodoo 1 can do 800x600 and the Voodoo 2 can do
+1024x768 at best, but still it has some use as a second head in 
+Xinerama or multihead mode.
+
+16 and 24 bpp modes are supported (24 bit in 32-bit sparse-packed
+mode).
+
+Further information about this driver can be found in the 'glide' driver
+manpage for XFree86. You will not get this driver running before
+reading this manpage.
+
+For Voodoo Banshee and Voodoo 3 boards or later: Please use the tdfx
+driver which talks directly to the hardware and is much faster.
 
 <sect>X libraries and clients
 <p>
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml
index 7c7be3479..745190cb5 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml
@@ -10,7 +10,7 @@
 <date>17 April 1999
 
 <ident>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.5 1999/07/19 13:36:21 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.6 1999/10/13 04:21:08 dawes Exp $
 </ident>
 
 <!-- Table of contents -->
@@ -19,7 +19,7 @@ $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/SiS.sgml,v 3.5 1999/07/19 13:3
 <sect> Introduction <p>
 
 This driver was primarily written for the SiS6326 and SiS530 by Alan Hourihane.
-It also works on 5597/5598 chips, and probably on older SiS862XX family.
+It also works on 5597/5598 chips, and probably on older SiS862X5 family.
 
 The driver supports :
 <itemize>
@@ -33,9 +33,12 @@ The driver supports :
 <sect> Supported chips <p>
 
 <quote>
-SiS 530, SiS 86c201, SiS 86c202, SiS 86c2x5, SiS 5597/5598, SiS 6326
+SiS 530, SiS 86c2x5, SiS 5597/5598, SiS 6326
 </quote>
 
+This driver needs linear framebuffer support in the card. Because this 
+SiS 86C201 and 86C202 based cards don't work with this driver.
+
 Color expansion is not supported by the engine in 16M-color graphic mode.
 
 <sect> XF86Config Options <p>
@@ -103,8 +106,6 @@ driver you'll need to consider several points:
 
 <sect> Troubleshooting <p>
 
-6326 based cards with more than 4Mb of RAM probably don't work.
-
 The generic VGA driver don't work with 6326, so XF86Setup can't be used
 for this card. Please use xf86config instead.
 
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml
index 2966f3388..e363364ab 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml
@@ -8,10 +8,10 @@
 
 <title>ATI Adapters README file
 <author>Marc Aurele La France
-<date>1999 July 8
+<date>1999 October 25
 
 <ident>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.25 1999/08/21 13:48:29 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/ati.sgml,v 3.28 1999/10/26 15:58:15 tsi Exp $
 </ident>
 
 <abstract>
@@ -79,7 +79,8 @@ VGAWonder series:  18800, 18800-1, 28800-2, 28800-4, 28800-5, 28800-6
    Mach64 series:  88800GX-C, 88800GX-D, 88800GX-E, 88800GX-F, 88800CX,
                    264CT, 264ET, 264VT, 264GT (3D Rage), 264VT-B, 264VT3,
                    264VT4, 264GT-B (3D Rage II), 3D Rage IIc, 3D Rage Pro,
-                   3D Rage LT, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC</verb>
+                   3D Rage LT, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC,
+                   3D Rage Mobility</verb>
 The driver also supports 32K, 64K and 16M-colour modes on the 264xT and 3D Rage
 series of adapters using the accelerator CRTC (but not the VGA CRTC).
 This support is as yet unaccelerated.<p>
@@ -337,11 +338,34 @@ clocks, the second of which will be assumed to be 28.322MHz.
 You can include up to four clock frequencies in your XF86Config to specify the
 actual values used by the adapter.
 Any more will be ignored.<p>
+<sect1>Option <it>``crt_screen''</it><p>
+This specification is only effective when the driver detects that the adapter's
+BIOS has initialized both the digital flat panel and CRT interfaces.
+In such a situation, the driver will normally drive the panel and disable the
+CRT.
+This specification causes the driver to disable the digital flat panel and
+display the screen image on the CRT instead.<p>
 <sect1>Option <it>``nolinear''</it><p>
 By default, the driver will enable a linear video memory aperture for
 256-colour and higher depth modes if it is also using a Mach64 accelerator CRTC
 or an integrated Mach64 graphics chip.
 This option disables this linear aperture.<p>
+<sect1>Option <it>``shadowfb''</it><p>
+If this option is enabled, the driver will cause the CPU to do each drawing
+operation first into a shadow frame buffer in system virtual memory and then
+copy the result into video memory.
+If this option is not active, the CPU will draw directly into video memory.
+Enabling this option is beneficial for those systems where reading from video
+memory is, on average, slower than the corresponding read/modify/write
+operation in system virtual memory.
+This is normally the case for PCI or AGP adapters, and, so, this option is
+enabled by default.
+For other bus types, the default behaviour is to disable this option.<p>
+Note that, due to various limitations, this option is forcibly disabled when a
+linear video memory aperture is not enabled, or when the frame buffer depth is
+less than 8.
+The use of video acceleration, when implemented in a future driver release,
+will also disable frame buffer shadowing.<p>
 <sect1>MemBase <it>address</it><p>
 This specification is only effective for non-PCI Mach64 adapters, and is used
 to override the CPU address at which the adapter will map its video memory.
@@ -369,11 +393,6 @@ A system conflict with APM.
 This problem is Linux-specific.
 There is a bug in kernels 2.0.31 or earlier that prevents proper APM operation.
 Upgrade to a more recent kernel or disable APM support.<p>
-The TV port on some Mach64 adapters needs to be disabled using an ATI utility
-that might or might not be supplied with the adapter.
-This problem is still under investigation.
-The only known workaround is to ensure no cable is connected to the adapter's
-TV connector on bootup.
 <item>When using a Mach64's accelerator CRTC, the virtual resolution must be
 less than 8192 pixels wide.
 The VGA CRTC further limits the virtual resolution width to less than 4096
@@ -390,10 +409,9 @@ accelerator CRTC in 88800GX, 88800CX, 264CT and 264ET adapters.
 CRTC.
 <item>Interlaced modes are not supported on 18800-x and 28800-x adapters when
 using a virtual resolution that is 2048 pixels or wider.
+When using a 18800-x with 256kB of video memory in 256-colour modes, this limit
+is reduced to 1024.
 This is yet another hardware limitation that cannot be circumvented.
-For now, the driver prevents the occurrence of this problem by restricting
-virtual resolutions to be less than 2048 pixels wide, even when no interlaced
-modes are specified.
 <item>Video memory banking does not work in monochrome and 16-colour modes on
 18800-x adapters.
 This appears to be another hardware limit, but this conclusion cannot be
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent b/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent
index 7975e307b..6d7979f85 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent
@@ -1,12 +1,12 @@
-<!-- $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent,v 1.4 1999/08/21 14:08:30 dawes Exp $ -->
+<!-- $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/defs.ent,v 1.5 1999/12/31 22:30:29 robin Exp $ -->
 
 <!-- shared entity definitions for the XFree86 documentation -->
 
 <!-- XFree86 version string -->
-<!ENTITY relvers CDATA "3.9.16">
-<!ENTITY prevrelvers CDATA "3.9.15">
-<!ENTITY srcvers CDATA "3916">
-<!ENTITY prevsrcvers CDATA "3915">
+<!ENTITY relvers CDATA "3.9.17">
+<!ENTITY prevrelvers CDATA "3.9.16">
+<!ENTITY srcvers CDATA "3917">
+<!ENTITY prevsrcvers CDATA "3916">
 
 <!-- Swap these for the next snapshot -->
 <!ENTITY % firstsnap 'IGNORE'>
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/r128.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/r128.sgml
new file mode 100644
index 000000000..2175e1d67
--- /dev/null
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/r128.sgml
@@ -0,0 +1,133 @@
+<!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN">
+
+<article>
+<title>Information for ATI Rage 128 Users
+<author>Precision Insight, Inc., SuSE GmBH
+<date>12 November 1999
+<toc>
+
+<sect>Supported Hardware
+<p>
+<itemize>
+  <item>ATI Rage 128 based cards
+</itemize>
+
+
+<sect>Features
+<p>
+<itemize>
+  <item>Full support (including hardware accelerated 2D drawing) for 8, 15,
+        16, 24, and 32 bit per pixel depths.
+  <item>Hardware cursor support to reduce sprite flicker.
+  <item>Support for high resolution video modes up to 1800x1440 @ 70Hz.
+  <item>Support for doublescan video modes (e.g., 320x200 and 320x240).
+  <item>Support for gamma correction at all pixel depths.
+  <item>Fully programmable clock supported.
+  <item>Robust text mode restore for VT switching.
+</itemize>
+
+
+<sect>Technical Notes
+<p>
+<itemize>
+  <item>None
+</itemize>
+
+
+<sect>Reported Working Video Cards
+<p>
+<itemize>
+  <item>Rage Fury AGP 32MB
+  <item>XPERT 128 AGP 16MB
+  <item>XPERT 99 AGP 8MB
+</itemize>
+
+
+<sect>Configuration
+<p>
+The driver auto-detects all device information necessary to
+initialize the card.  The only lines you need in the "Device"
+section of your XF86Config file are:
+<verb>
+       Section "Device"
+           Identifier "r128"
+       EndSection
+</verb>
+or let xf86config or XF86Setup do this for you.
+
+However, if you have problems with auto-detection, you can specify:
+<itemize>
+  <item>VideoRam - in kilobytes
+  <item>MemBase  - physical address of the linear framebuffer
+  <item>IOBase   - physical address of the memory mapped IO registers
+  <item>ChipID   - PCI DEVICE ID
+</itemize>
+
+
+<sect>Driver Options
+<p>
+<itemize>
+  <item>"hw_cursor" - request hardware cursor (default)
+  <item>"sw_cursor" - software cursor only
+  <item>"no_accel"  - software rendering only
+  <item>"dac_8_bit" - use color weight 888 in 8 bpp mode (default)
+  <item>"dac_6_bit" - use color weight 666 in 8 bpp mode (VGA emulation)
+</itemize>
+
+
+<sect>Known Limitations
+<p>
+<itemize>
+  <item>None
+</itemize>
+
+
+<sect>Authors
+<p>
+The XFree86 3.9 driver was ported from XFree86 3.3 and enhanced by:
+<itemize>
+   <item>Rickard E. (Rik) Faith <it>&lt;faith@precisioninsight.com&gt;</it>
+   <item>Kevin E. Martin <it>&lt;kevin@precisioninsight.com&gt;</it>
+</itemize>
+<p>
+The XFree86 3.9 driver was funded by ATI and was donated to The XFree86
+Project by:
+<verb>
+    Precision Insight, Inc.
+    Cedar Park, TX
+    USA
+</verb>
+<p>
+The XFree86 3.3 driver used for the port was written by:
+<itemize>
+   <item>Rickard E. (Rik) Faith <it>&lt;faith@precisioninsight.com&gt;</it>
+   <item>Kevin E. Martin <it>&lt;kevin@precisioninsight.com&gt;</it>
+</itemize>
+The XFree86 3.3 driver was funded by ATI and was donated to The XFree86
+Project by Precision Insight, Inc.  It was based in part on an earlier
+driver that was written by:
+<itemize>
+   <item>Alan Hourihane <it>&lt;alanh@fairlite.demon.co.uk&lt;</it>
+   <item>Dirk Hohndel <it>&lt;hohndel@suse.de&gt;</it>
+</itemize>
+<p>This early driver was funded and donated to The XFree86 Project by:
+<verb>
+    SuSE GmbH
+    Schanzaekerstr. 10
+    90443 Nuernberg
+    Germany
+</verb>
+
+<p>
+<htmlurl name="http://www.precisioninsight.com"
+          url="http://www.precisioninsight.com">
+<p>
+<htmlurl name="http://www.suse.com"
+          url="http://www.suse.com">
+
+<verb>
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/r128.sgml,v 1.2 1999/11/19 13:54:28 hohndel Exp $
+$PI: xc/programs/Xserver/hw/xfree86/doc/sgml/r128.sgml,v 1.2 1999/10/21 20:51:15 faith Exp $
+</verb>
+
+</article>
diff --git a/xc/programs/Xserver/hw/xfree86/doc/sgml/rendition.sgml b/xc/programs/Xserver/hw/xfree86/doc/sgml/rendition.sgml
index 230c010ac..85d4ecf47 100644
--- a/xc/programs/Xserver/hw/xfree86/doc/sgml/rendition.sgml
+++ b/xc/programs/Xserver/hw/xfree86/doc/sgml/rendition.sgml
@@ -3,22 +3,28 @@
 <article>
 <title>Information for Rendition Users
 <author>The XFree86 Project Inc.
-<date>1 August 1999
+<date>12 December 1999
 <toc>
 
 <sect>Supported hardware <p>
 All cards based on the V1000 or the V2x00 should be supported. The server
 was tested on a miroCRYSTAL VRX (V1000), Intergraph Intense-100 3D (V1000), Diamond Stealth II S220 (V2100), Hercules Thriller3D (V2200) and Innovision Warrior3D (V2200).
 
-<sect>Important notices <p>
+<sect>Limitations <p>
 V1000 cards can only work as primary display card due to hardware limitations. <p>
+V2x00 cards can work even if not primary, but primary display card will be disabled when server is run. This is a driver limitation.<p>
+Hopefully these limitations will be workaround and fixed before final XFree4.0 release.<p>
+
+<sect>Important notices <p>
 Some V1000-based video cards are known to lock up the computer if you have write-combine activated. Disabling it removes the problem. Look for settings in the motherboards BIOS and disable ALL settings that has to do with write-combine (usually called USWC or just WC for short). <p>
-The "chipset" option is now implemented and honored when used. Unfortunately some legacy-code in the driver is preventing it from working with any cards but the primary display card. <p>
-If you have problems with hardware cursor use the "sw_cursor" option to revert back to software cursor.
+
+15 bits per pixel is only supported on V1000-based cards due to hardware limitations on V2x00 chipsets.<p>
+
+If you have problems with hardware cursor use the "sw_cursor" option to revert back to software cursor.<p>
 
 <sect>Features <p>
 <itemize>
-<item>Unaccelerated
+<item>Hardware acceleration
 <item>Hardware cursor
 <item>Supported color depths
 <itemize>
@@ -39,36 +45,37 @@ at higher resolutions. But adds the risk to damage the hardware. Use with
 caution.
 <tag>DacSpeed "MHz"</tag>
 Set custom ramdac limit. We have currently no way of knowing if the v2x00 chip is a v2100 (170MHz) or v2200 (203MHz and 230MHz) so we assume the lowest. Use this option to manually override the value.
+<tag>Option "FramebufferWC"</tag>
+If writecombine is disabled in BIOS, and you add this option in in configuration file, then the driver will try to request writecombined access to the framebuffer. This can drasticly increase the preformance on unaccelerated server. Requres that "MTRR"-support is compiled into the OS-kernel.
+<tag>Option "NoDDC"</tag>
+Disable probing of DDC-information from your monitor. This information is not used yet and is only there for informational purposes. This might change before final XFree86 4.0 release. Safe to disable if you experience problems during startup of X-server.
 </descrip>
 
 <sect>News in this release <p>
 <itemize>
-<item>Hardware-cursor on V2x00 cards.
+<item>Acceleration! Disabled for the moment.
 </itemize>
 
 <sect>Major fixes in this release <p>
 <itemize>
-<item>Depth 15 works on V1000 cards.
-<item>Bandwidth limits are now included. Can be overridden with DacSpeed option.
+<item>To be determined before final release.
 </itemize>
 
 <sect>Known problems in current driver<p>
 <itemize>
-<item>Displays with depth 15 ("-bpp 15" or "-bpp 16 -weight 555") has problems on V2x00 cards.
+<item>The acceleration code hangs the computer during X-server startup.
+<item>DDC-probing does not work correclty yet. No DDC information is found.
 <item>Switching from display to VC and back to display can lock up V2x00 cards.
 <item>When scrolling the virtual display on a V1000 card parts of the screen will become distorted. Problem disappears when you continue moving around. V2x00 does not exhibit this problem. Probably a bug in the driver rather than a limitation of the chip.
-<item>Option "chipset" is honored. Unfortunately the driver still has problems and will only work if the rendition card is the primary display card in the system.
-<item>If an incorrect mode was given, the server does not restore console to correct state.
 </itemize>
 
 <sect>Work in progress (not finished in time for release) <p>
 <itemize>
-<item>Acceleration for V1000 chipset. Some bugs to clear out.
-<item>Acceleration for V2100 and V2200 chipset. Not ready for general use.
+<item>Acceleration is disabled for the moment. If you want to play with it enable the "USE_ACCEL" define in rendition.c file! Beware as it has several bugs left to clear out before if is stable for general use.
 </itemize>
 
 <verb>
-$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/rendition.sgml,v 1.3 1999/08/28 10:43:34 dawes Exp $
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/rendition.sgml,v 1.4 1999/12/14 03:12:08 robin Exp $
 </verb>
 
 </article>
diff --git a/xc/programs/Xserver/hw/xfree86/doc/smartsched b/xc/programs/Xserver/hw/xfree86/doc/smartsched
new file mode 100644
index 000000000..3d5a84b9b
--- /dev/null
+++ b/xc/programs/Xserver/hw/xfree86/doc/smartsched
@@ -0,0 +1,204 @@
+			Client Scheduling in X
+			    Keith Packard
+			       SuSE
+			     10/28/99
+
+History:
+
+Since the original X server was written at Digital in 1987, the OS and DIX
+layers shared responsibility for scheduling the order to service
+client requests.  The original design was simplistic; under the maximum
+first make it work, then make it work well, this was a good idea.  Now 
+that we have a bit more experience with X applications, it's time to
+rethink the design.
+
+The basic dispatch loop in DIX looks like:
+
+	for (;;)
+	{
+		nready = WaitForSomething (...);
+		while (nready--)
+		{
+			isItTimeToYield = FALSE;
+			while (!isItTimeToYield)
+			{
+				if (!ReadRequestFromClient (...))
+					break;
+				(execute request);
+			}
+		}
+	}
+
+WaitForSomething looks like:
+
+	for (;;)
+		if (ANYSET (ClientsWithInput))
+			return popcount (ClientsWithInput);
+		select (...)
+		compute clientsReadable from select result;
+		return popcount (clientsReadable)
+	}
+
+ReadRequestFromClient looks like:
+
+	if (!fullRequestQueued)
+	{
+		read ();
+		if (!fullRequestQueued)
+		{
+			remove from ClientsWithInput;
+			timesThisConnection = 0;
+			return 0;
+		}
+	}
+	if (twoFullRequestsQueued)
+		add to ClientsWithInput;
+
+	if (++timesThisConnection >= 10)
+	{
+		isItTimeToYield = TRUE;
+		timesThisConnection = 0;
+	}
+	return 1;
+
+Here's what happens in this code:
+
+With a single client executing a stream of requests:
+
+	A client sends a packet of requests to the server.
+
+	WaitForSomething wakes up from select and returns that client
+	to Dispatch
+
+	Dispatch calls ReadRequestFromClient which reads a buffer (4K)
+	full of requests from the client
+
+	The server executes requests from this buffer until it emptys,
+	in two stages -- 10 requests at a time are executed in the
+	inner Dispatch loop, a buffer full of requests are executed
+	because WaitForSomething immediately returns if any clients
+	have complete requests pending in their input queues.
+
+	When the buffer finally emptys, the next call to ReadRequest
+	FromClient will return zero and Dispatch will go back to
+	WaitForSomething; now that the client has no requests pending,
+	WaitForSomething will block in select again.  If the client
+	is active, this select will immediately return that client
+	as ready to read.
+
+With multiple clients sending streams of requests, the sequence
+of operations is similar, except that ReadRequestFromClient will
+set isItTimeToYield after each 10 requests executed causing the
+server to round-robin among the clients with available requests.
+
+It's important to realize here that any complete requests which have been
+read from clients will be executed before the server will use select again
+to discover input from other clients.  A single busy client can easily
+monopolize the X server.
+
+So, the X server doesn't share well with clients which are more interactive
+in nature.
+
+The X server executes at most a buffer full of requests before again heading
+into select; ReadRequestFromClient causes the server to yield when the
+client request buffer doesn't contain a complete request.  When
+that buffer is executed quickly, the server spends a lot of time
+in select discovering that the same client again has input ready.  Thus
+the server also runs busy clients less efficiently than is would be
+possible.
+
+What to do.
+
+There are several things evident from the above discussion:
+
+ 1	The server has a poor metric for deciding how much work it
+	should do at one time on behalf of a particular client.
+
+ 2	The server doesn't call select often enough to detect less
+ 	aggressive clients in the face of busy clients, especially
+	when those clients are executing slow requests.
+
+ 3	The server calls select too often when executing fast requests.
+
+ 4	Some priority scheme is needed to keep interactive clients
+ 	responding to the user.
+
+And, there are some assumptions about how X applications work:
+
+ 1	Each X request is executed relatively quickly; a request-granularity
+ 	is good enough for interactive response almost all of the time.
+
+ 2	X applications receiving mouse/keyboard events are likely to
+ 	warrant additional attention from the X server.
+
+Instead of a request-count metric for work, a time-based metric should be
+used.  The server should select a reasonable time slice for each client
+and execute requests for the entire timeslice before yielding to
+another client.
+
+Instead of returning immediately from WaitForSomething if clients have
+complete requests queued, the server should go through select each
+time and gather as many ready clients as possible.  This involves
+polling instead of blocking and adding the ClientsWithInput to
+clientsReadable after the select returns.
+
+Instead of yielding when the request buffer is empty for a particular
+client, leave the yielding to the upper level scheduling and allow
+the server to try and read again from the socket.  If the client
+is busy, another buffer full of requests will already be waiting
+to be delivered thus avoiding the call through select and the
+additional overhead in WaitForSomething.
+
+Finally, the dispatch loop should not simply execute requests from the
+first available client, instead each client should be prioritized with
+busy clients penalized and clients receiving user events praised.
+
+How it's done:
+
+Polling the current time of day from the OS is too expensive to
+be done at each request boundary, so instead an interval timer is
+set allowing the server to track time changes by counting invocations
+of the related signal handler.  Instead of using the wall time for
+this purpose, the process CPU time is used instead.  This serves
+two purposes -- first, it allows the server to consume no CPU cycles
+when idle, second it avoids conflicts with SIGALRM usage in other
+parts of the server code.  It's not without problems though; other
+CPU intensive processes on the same machine can reduce interactive
+response time within the X server.  The dispatch loop can now
+calculate an approximate time value using the number of signals
+received.  The granularity of the timer sets the scheduling jitter,
+at 20ms it's only occasionally noticeable.
+
+The changes to WaitForSomething and ReadRequestFromClient are
+straightforward, adjusting when select is called and avoiding
+setting isItTimeToYield too often.
+
+The dispatch loop changes are more extensive, now instead of
+executing requests from all available clients, a single client
+is chosen after each call to WaitForSomething, requests are
+executed for that client and WaitForSomething is called again.
+
+Each client is assigned a priority, the dispatch loop chooses the
+client with the highest priority to execute.  Priorities are
+updated in three ways:
+
+ 1.	Clients which consume their entire slice are penalized
+ 	by having their priority reduced by one until they
+	reach some minimum value.
+
+ 2.	Clients which have executed no requests for some time
+ 	are praised by having their priority raised until they
+	return to normal priority.
+
+ 3.	Clients which receive user input are praised by having
+ 	their priority rased until they reach some maximal
+	value, above normal priority.
+
+The effect of these changes is to both improve interactive application
+response and benchmark numbers at the same time.
+
+
+
+
+
+$XFree86: xc/programs/Xserver/hw/xfree86/doc/smartsched,v 1.2 1999/11/19 14:59:16 hohndel Exp $