Used synchronise script to update files

5 files changed, 1462 insertions, 1460 deletions

diff --git a/xorg-server/hw/xfree86/doc/.gitignore b/xorg-server/hw/xfree86/doc/.gitignore
new file mode 100644
index 000000000..63eee5960
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/.gitignore
@@ -0,0 +1,4 @@
+ddxDesign.html
+ddxDesign.pdf
+ddxDesign.ps
+ddxDesign.txt
diff --git a/xorg-server/hw/xfree86/doc/README.DRIcomp b/xorg-server/hw/xfree86/doc/README.DRIcomp
index 617897949..2d3ebf148 100644
--- a/xorg-server/hw/xfree86/doc/README.DRIcomp
+++ b/xorg-server/hw/xfree86/doc/README.DRIcomp
@@ -1,554 +1,554 @@
-                            DRI Compilation Guide

-

-          VA Linux Systems, Inc. Professional Services - Graphics.

-

-                                21 April 2001

-

-1.  Preamble

-

-1.1  Copyright

-

-Copyright 2000-2001 by VA Linux Systems, Inc.  All Rights Reserved.

-

-Permission is granted to make and distribute verbatim copies of this document

-provided the copyright notice and this permission notice are preserved on all

-copies.

-

-1.2  Trademarks

-

-OpenGL is a registered trademark and SGI is a trademark of Silicon Graphics,

-Inc.  Unix is a registered trademark of The Open Group.  The `X' device and X

-Window System are trademarks of The Open Group.  XFree86 is a trademark of

-The XFree86 Project.  Linux is a registered trademark of Linus Torvalds.

-Intel is a registered trademark of Intel Corporation.  3Dlabs, GLINT, and

-Oxygen are either registered trademarks or trademarks of 3Dlabs Inc. Ltd.

-3dfx, Voodoo3, Voodoo4, and Voodoo5 are registered trademarks of 3dfx Inter-

-active, Incorporated.  Matrox is a registered trademark of Matrox Electronic

-Systems Ltd.  ATI Rage and Radeon is a registered trademark of ATI Technolo-

-gies, Inc.  All other trademarks mentioned are the property of their respec-

-tive owners.

-

-2.  Introduction

-

-This document describes how to download, compile and install the DRI.  The

-DRI provides 3D graphics hardware acceleration for the XFree86 project.  This

-information is intended for experienced Linux developers.  Beginners are

-probably better off installing precompiled packages.

-

-Edits, corrections and updates to this document may be mailed to <brian@tung-

-stengraphics.com>.

-

-Last updated on 13 February 2002 by Brian Paul.

-

-3.  Prerequisites

-

-You'll need the following:

-

-   o An installation of XFree86 4.1 or later.  The DRI tree has been pruned

-     down to minimize its size.  But in order to build the DRI tree you need

-     to have recent X header files, etc. already installed.  If you don't

-     have XFree86 4.1 (or later) installed you can probably install it from

-     RPMs (or another package format).  Or, you can download XFree86 as

-     sources and compile/install it yourself.

-

-   o At least 200MB of free disk space.  If you compile for debugging (the -g

-     option) then you'll need about 600MB.

-

-   o GCC compiler and related tools.

-

-   o ssh (secure shell) if you're a DRI developer and don't want to use

-     anonymous CVS download.

-

-   o A 2.4.x Linux Kernel.  See below for details.

-

-   o FreeBSD support is not currently being maintained and may not work.

-

-The DRI 3D drivers generally work on systems with Intel or AMD CPUs.  How-

-ever, limited support for Alpha and PowerPC support is underway.

-

-For 3dfx Voodoo hardware, you'll also need the Glide3 runtime library

-(libglide3-v3.so for Voodoo3 or libglide3-v5.so for Voodoo4/5).  These can be

-downloaded from the DRI website.  You can compile them yourself, but it's

-often a painful process.

-

-For Matrox G200/G400, Intel i810/i830 or ATI Rage128/Radeon hardware, you'll

-also need AGP support in your Linux kernel, either built-in or as a loadable

-module.

-

-4.  Linux Kernel Preparation

-

-Only the Linux 2.4.x kernels are currently supported by the DRI hardware

-drivers.  2.5.x kernels may work, but aren't tested.

-

-Most of the DRI drivers require AGP support and using Intel Pentium III SSE

-optimizations also requires an up-to-date Linux kernel.  Configuring your

-kernel correctly is very important, as features such as SSE optimizations

-will be disabled if your kernel does not support them.  Thus, if you have a

-Pentium III processor, you must configure your kernel for the Pentium III

-processor family.

-

-Building a new Linux kernel can be difficult for beginners but there are

-resources on the Internet to help.  This document assumes experience with

-configuring, building and installing Linux kernels.

-

-Linux kernels can be downloaded from www.kernel.org

-

-Here are the basic steps for kernel setup.

-

-   o Download the needed kernel and put it in /usr/src.  Create a directory

-     for the source and unpack it.  For example:

-

-                    cd /usr/src

-                    rm -f linux

-                    mkdir linux-2.4.x

-                    ln -s linux-2.4.x linux

-                    bzcat linux-2.4.x.tar.bz2 | tar xf -

-

-     It is critical that /usr/src/linux point to your new kernel sources,

-     otherwise the kernel headers will not be used when building the DRI.

-     This will almost certainly cause compilation problems.

-

-   o Read /usr/src/linux/Documentation/Changes.  This file lists the minimum

-     requirements for all software packages required to build the kernel.

-     You must upgrade at least gcc, make, binutils and modutils to at least

-     the versions specified in this file.  The other packages may not be

-     needed.  If you are upgrading from Linux 2.2.x you must upgrade your

-     modutils package for Linux 2.4.x.

-

-   o Configure your kernel.  You might, for example, use make menuconfig and

-     do the following:

-

-        o Go to Code maturity level options

-

-        o Enable Prompt for development and/or incomplete code/drivers

-

-        o hit ESC to return to the top-level menu

-

-        o Go to Processor type and features

-

-        o Select your processor type from Processor Family

-

-        o hit ESC to return to the top-level menu

-

-        o Go to Character devices

-

-        o Disable Direct Rendering Manager (XFree86 DRI support) since we'll

-          use the DRI code from the XFree86/DRI tree and will compile it

-          there.

-

-        o Go to /dev/agpgart (AGP Support) (EXPERIMENTAL) (NEW)

-

-        o Hit SPACE twice to build AGP support into the kernel

-

-        o Enable all chipsets' support for AGP

-

-        o It's recommended that you turn on MTRRs under Processor type and

-          Features, but not required.

-

-   o Configure the rest of the kernel as required for your system (i.e. Eth-

-     ernet, SCSI, etc)

-

-   o Exit, saving your kernel configuration.

-

-   o Edit your /etc/lilo.conf file.  Make sure you have an image entry as

-     follows (or similar):

-

-                      image=/boot/vmlinuz

-                            label=linux.2.4.x

-                            read-only

-                            root=/dev/hda1

-

-     The important part is that you have /boot/vmlinuz without a trailing

-     version number.  If this is the first entry in your /etc/lilo.conf AND

-     you haven't set a default, then this will be your default kernel.

-

-   o Compile the new kernel.

-

-                    cd /usr/src/linux-2.4.x

-                    make dep

-                    make bzImage

-                    make modules

-                    make modules_install

-                    make install

-

-     Note that last make command will automatically run lilo for you.

-

-   o Now reboot to use the new kernel.

-

-5.  CPU Architectures

-

-In general, nothing special has to be done to use the DRI on different CPU

-architectures.  There are, however, a few optimizations that are CPU-depen-

-dent.  Mesa will determine at runtime which CPU-dependent optimizations

-should be used and enable them where appropriate.

-

-5.1  Intel Pentium III Features

-

-The Pentium III SSE instructions are used in optimized vertex transformation

-functions in the Mesa-based DRI drivers.  On Linux, SSE requires a recent

-kernel (such as 2.4.0-test11 or later) both at compile time and runtime.

-

-5.2  AMD 3DNow! Features

-

-AMD's 3DNow! instructions are used in optimized vertex transformation func-

-tions in the Mesa-based DRI drivers.  3DNow! is supported in most versions of

-Linux.

-

-5.3  Alpha Features

-

-On newer Alpha processors a significant performance increase can be seen with

-the addition of the -mcpu= option to GCC.  This option is dependent on the

-architecture of the processor.  For example, -mcpu=ev6 will build specifi-

-cally for the EV6 based AXP's, giving both byte and word alignment access to

-the DRI/Mesa drivers.

-

-To enable this optimization edit your xc/config/host.def file and add the

-line:

-

-#define DefaultGcc2AxpOpt -O2 -mcpu=ev6

-

-Additional speed improvements to 3D rendering can be achieved by installing

-Compaq's Math Libraries (CPML) which can be obtained from http://www.sup-

-port.compaq.com/alpha-tools/software/index.html

-

-Once installed, you can add this line to your host.def to build with the CPML

-libraries:

-

-#define UseCompaqMathLibrary YES

-

-The host.def file is explained below.

-

-6.  Downloading the XFree86/DRI CVS Sources

-

-The DRI project is hosted by SourceForge.  The DRI source code, which is a

-subset of the XFree86 source tree, is kept in a CVS repository there.

-

-The DRI CVS sources may be accessed either anonymously or as a registered

-SourceForge user.  It's recommended that you become a registered SourceForge

-user so that you may submit non-anonymous bug reports and can participate in

-the mailing lists.

-

-6.1  Anonymous CVS download:

-

-  1.  Create a directory to store the CVS files:

-

-                       cd ~

-                       mkdir DRI-CVS

-

-      You could put your CVS directory in a different place but we'll use

-      ~/DRI-CVS/ here.

-

-  2.  Check out the CVS sources:

-

-                       cd ~/DRI-CVS

-                       cvs -d:pserver:anonymous@cvs.dri.sourceforge.net:/cvsroot/dri login

-                         (hit ENTER when prompted for a password)

-                       cvs -z3 -d:pserver:anonymous@cvs.dri.sourceforge.net:/cvsroot/dri co xc

-

-      The -z3 flag causes compression to be used in order to reduce the down-

-      load time.

-

-6.2  Registered CVS download:

-

-  1.  Create a directory to store the CVS files:

-

-                       cd ~

-                       mkdir DRI-CVS

-

-      You could put your CVS directory in a different place but we'll use

-      ~/DRI-CVS/ here.

-

-  2.  Set the CVS_RSH environment variable:

-

-                       setenv CVS_RSH ssh      // if using csh or tcsh

-                       export CVS_RSH=ssh      // if using sh or bash

-

-  3.  Check out the CVS sources:

-

-                       cd ~/DRI-CVS

-                       cvs -z3 -d:ext:YOURID@cvs.dri.sourceforge.net:/cvsroot/dri co xc

-

-      Replace YOURID with your CVS login name.  You'll be prompted to enter

-      your sourceforge password.

-

-      The -z3 flag causes compression to be used in order to reduce the down-

-      load time.

-

-6.3  Updating your CVS sources

-

-In the future you'll want to occasionally update your local copy of the DRI

-source code to get the latest changes.  This can be done with:

-

-                cd ~/DRI-CVS

-                cvs -z3 update -dA xc

-

-The -d flag causes any new subdirectories to be created and -A causes most

-recent trunk sources to be fetched, not branch sources.

-

-7.  Mesa

-

-Most of the DRI 3D drivers are based on Mesa (the free implementation of the

-OpenGL API).  The relevant files from Mesa are already included in the

-XFree86/DRI source tree.  There is no need to download or install the Mesa

-source files separately.

-

-Sometimes a newer version of Mesa will be available than the version included

-in XFree86/DRI.  Upgrading Mesa within XFree86/DRI is not always straightfor-

-ward.  It can be an error-prone undertaking, especially for beginners, and is

-not generally recommended.  The DRI developers will upgrade Mesa when appro-

-priate.

-

-8.  Compiling the XFree86/DRI tree

-

-8.1  Make a build tree

-

-Rather than placing object files and library files right in the source tree,

-they're instead put into a parallel build tree.  The build tree is made with

-the lndir command:

-

-                 cd ~/DRI-CVS

-                 ln -s xc XFree40

-                 mkdir build

-                 cd build

-                 lndir -silent -ignorelinks ../XFree40

-

-The build tree will be populated with symbolic links which point back into

-the CVS source tree.

-

-Advanced users may have several build trees for compiling and testing with

-different options.

-

-8.2  Edit the host.def file

-

-The ~/DRI-CVS/build/xc/config/cf/host.def file is used to configure the

-XFree86 build process.  You can change it to customize your build options or

-make adjustments for your particular system configuration

-

-The default host.def file will look something like this:

-

-                 #define DefaultCCOptions -Wall

-     (i386)      #define DefaultGcc2i386Opt -O2

-     (Alpha)     #define DefaultGcc2AxpOpt -O2 -mcpu=ev6 (or similar)

-                 #define LibraryCDebugFlags -O2

-                 #define BuildServersOnly YES

-                 #define XF86CardDrivers vga tdfx mga ati i810

-                 #define LinuxDistribution LinuxRedHat

-                 #define DefaultCCOptions -ansi GccWarningOptions -pipe

-                 #define BuildXF86DRI YES

-                 /* Optionally turn these on for debugging */

-                 /* #define GlxBuiltInTdfx YES */

-                 /* #define GlxBuiltInMga YES */

-                 /* #define GlxBuiltInR128 YES */

-                 /* #define GlxBuiltInRadeon YES */

-                 /* #define DoLoadableServer NO */

-                 #define SharedLibFont NO

-

-The ProjectRoot variable specifies where the XFree86 files will be installed.

-We recommend installing the DRI files over your existing XFree86 installation

-- it's generally safe to do and less error-prone.  This policy is different

-than what we used to recommend.

-

-If XFree86 4.x is not installed in /usr/X11R6/ you'll have to add the follow-

-ing to the host.def file:

-

-                 #define ProjectRoot pathToYourXFree86installation

-

-Note the XF86CardDrivers line to be sure your card's driver is listed.

-

-If you want to enable 3DNow! optimizations in Mesa and the DRI drivers, you

-should add the following:

-

-                 #define MesaUse3DNow YES

-

-You don't have to be using an AMD processor in order to enable this option.

-The DRI will look for 3DNow! support and runtime and only enable it if appli-

-cable.

-

-If you want to enable SSE optimizations in Mesa and the DRI drivers, you must

-upgrade to a Linux 2.4.x kernel.  Mesa will verify that SSE is supported by

-both your processor and your operating system, but to build Mesa inside the

-DRI you need to have the Linux 2.4.x kernel headers in /usr/src/linux.  If

-you enable SSE optimizations with an earlier version of the Linux kernel in

-/usr/src/linux, Mesa will not compile.  You have been warned.  If you do have

-a 2.4.x kernel, you should add the following:

-

-                 #define MesaUseSSE YES

-

-If you want to build the DRM kernel modules as part of the full build pro-

-cess, add the following:

-

-                 #define BuildXF86DRM YES

-

-Otherwise, you'll need to build them separately as described below.

-

-8.3  Compilation

-

-To compile the complete DRI tree:

-

-                 cd ~/DRI-CVS/build/xc/

-                 make World >& world.log

-

-Or if you want to watch the compilation progress:

-

-                 cd ~/DRI-CVS/build/xc/

-                 make World >& world.log &

-                 tail -f world.log

-

-With the default compilation flags it's normal to get a lot of warnings dur-

-ing compilation.

-

-Building will take some time so you may want to go check your email or visit

-slashdot.

-

-WARNING: do not use the -j option with make.  It's reported that it does not

-work with XFree86/DRI.

-

-8.4  Check for compilation errors

-

-Using your text editor, examine world.log for errors by searching for the

-pattern ***.

-

-After fixing the errors, run make World again.  Later, you might just compile

-parts of the source tree but it's important that the whole tree will build

-first.

-

-If you edited your host.def file to enable automatic building of the DRI ker-

-nel module(s), verify that they were built:

-

-               cd ~/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel

-               ls

-

-Otherwise, build them now by running

-

-               cd ~/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel

-               make -f Makefile.linux

-

-For the 3dfx Voodoo, you should see tdfx.o.  For the Matrox G200/G400, you

-should see mga.o.  For the ATI Rage 128, you should see r128.o.  For the ATI

-Radeon, you should see radeon.o.  For the Intel i810, you should see i810.o.

-

-If the DRI kernel module(s) failed to build you should verify that you're

-using the right version of the Linux kernel.  The most recent kernels are not

-always supported.

-

-If your build machine is running a different version of the kernel than your

-target machine (i.e. 2.2.x vs. 2.4.x), make will select the wrong kernel

-source tree. This can be fixed by explicitly setting the value of LINUXDIR.

-If the path to your kernel source is /usr/src/linux-2.4.x,

-

-               cd ~/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel

-               make -f Makefile.linux LINUXDIR=/usr/src/linux-2.4.x

-

-or alternatively, edit Makefile.linux to set LINUXDIR before the ifndef LIN-

-UXDIR line.

-

-8.5  DRI kernel module installation

-

-The DRI kernel modules will be in ~/DRI-CVS/build/xc/pro-

-grams/Xserver/hw/xfree86/os-support/linux/drm/kernel/.

-

-To load the appropriate DRM module in your running kernel you can either use

-ismod and restart your X server or copy the kernel module to /lib/mod-

-ules/2.4.x/kernel/drivers/char/drm/ then run depmod and restart your X

-server.

-

-Make sure you first unload any older DRI kernel modules that might be already

-loaded.

-

-Note that some DRM modules require that the agpgart module be loaded first.

-

-9.  Normal Installation and Configuration

-

-Most users will want to install the new X server and use it in place of their

-old X server.  This section explains how to do that.

-

-Developers, on the other hand, may just want to test the X server without

-actually installing it as their default server.  If you want to do that, skip

-to the next section.

-

-9.1  Installation

-

-Here are the installation commands:

-

-                su

-                cd ~/DRI-CVS/build/xc

-                make install

-

-9.2  Update the XF86Config File

-

-You may need to edit your XF86Config file to enable the DRI.  The config file

-is usually installed as /etc/X11/XF86Config-4.  See the DRI User Guide for

-details, but basically, you need to load the "glx" and "dri" modules and add

-a "DRI" section.

-

-On the DRI web site, in the resources section, you'll find example XF86Config

-files for a number of graphics cards.  These configuration files also setup

-DRI options so it's highly recommended that you look at these examples.

-

-The XFree86 4.x server can generate a basic configuration file itself.  Sim-

-ply do this:

-

-                  cd /usr/X11R6/bin

-                  ./XFree86 -configure

-

-A file named /root/XF86Config.new will be created.  It should allow you to

-try your X server but you'll almost certainly have to edit it.  For example,

-you should add HorizSync and VertRefresh options to the Monitor section and

-Modes options to the Screen section.  Also, the ModulePath option in the

-Files section should be set to /usr/X11R6/lib/modules.

-

-9.3  Start the New X Server

-

-The new X server should be ready to use now.  Start your X server in your

-usual manner.  Often times the startx command is used:

-

-                  startx

-

-10.  Testing the Server Without Installing It

-

-As mentioned at the start of section 9, developers may want to simply run the

-X server without installing it.  This can save some time and allow you to

-keep a number of X servers available for testing.

-

-10.1  Configuration

-

-As described in the preceding section, you'll need to create a configuration

-file for the new server.  Put the XF86Config file in your ~/DRI-

-CVS/build/xc/programs/Xserver directory.

-

-Be sure the ModulePath option in your XF86Config file is set correctly.

-

-10.2  A Startup Script

-

-A simple shell script can be used to start the X server.  Here's an example.

-

-             #!/bin/sh

-             export DISPLAY=:0

-             ./XFree86 -xf86config XF86Config & \

-             sleep 2

-             fvwm2 &

-             xset b off

-             xmodmap -e "clear mod4"

-             xsetroot -solid "#00306f"

-             xterm -geometry 80x40+0+0

-

-You might name this script start-dri.  Put it in your ~/DRI-CVS/build/xc/pro-

-grams/Xserver directory.

-

-To test the server run the script:

-

-                  cd ~/DRI-CVS/build/xc/programs/Xserver

-                  ./start-dri

-

-For debugging, you may also want to capture the log messages printed by the

-server in a file.  If you're using the C-shell:

-

-                  ./start-dri >& log

-

-11.  Where To Go From Here

-

-At this point your X server should be up and running with hardware-acceler-

-ated direct rendering.  Please read the DRI User Guide for information about

-trouble shooting and how to use the DRI-enabled X server for 3D applications.

-

-     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml,v 1.19 dawes Exp $

+                            DRI Compilation Guide
+
+          VA Linux Systems, Inc. Professional Services - Graphics.
+
+                                21 April 2001
+
+1.  Preamble
+
+1.1  Copyright
+
+Copyright 2000-2001 by VA Linux Systems, Inc.  All Rights Reserved.
+
+Permission is granted to make and distribute verbatim copies of this document
+provided the copyright notice and this permission notice are preserved on all
+copies.
+
+1.2  Trademarks
+
+OpenGL is a registered trademark and SGI is a trademark of Silicon Graphics,
+Inc.  Unix is a registered trademark of The Open Group.  The `X' device and X
+Window System are trademarks of The Open Group.  XFree86 is a trademark of
+The XFree86 Project.  Linux is a registered trademark of Linus Torvalds.
+Intel is a registered trademark of Intel Corporation.  3Dlabs, GLINT, and
+Oxygen are either registered trademarks or trademarks of 3Dlabs Inc. Ltd.
+3dfx, Voodoo3, Voodoo4, and Voodoo5 are registered trademarks of 3dfx Inter-
+active, Incorporated.  Matrox is a registered trademark of Matrox Electronic
+Systems Ltd.  ATI Rage and Radeon is a registered trademark of ATI Technolo-
+gies, Inc.  All other trademarks mentioned are the property of their respec-
+tive owners.
+
+2.  Introduction
+
+This document describes how to download, compile and install the DRI.  The
+DRI provides 3D graphics hardware acceleration for the XFree86 project.  This
+information is intended for experienced Linux developers.  Beginners are
+probably better off installing precompiled packages.
+
+Edits, corrections and updates to this document may be mailed to <brian@tung-
+stengraphics.com>.
+
+Last updated on 13 February 2002 by Brian Paul.
+
+3.  Prerequisites
+
+You'll need the following:
+
+   o An installation of XFree86 4.1 or later.  The DRI tree has been pruned
+     down to minimize its size.  But in order to build the DRI tree you need
+     to have recent X header files, etc. already installed.  If you don't
+     have XFree86 4.1 (or later) installed you can probably install it from
+     RPMs (or another package format).  Or, you can download XFree86 as
+     sources and compile/install it yourself.
+
+   o At least 200MB of free disk space.  If you compile for debugging (the -g
+     option) then you'll need about 600MB.
+
+   o GCC compiler and related tools.
+
+   o ssh (secure shell) if you're a DRI developer and don't want to use
+     anonymous CVS download.
+
+   o A 2.4.x Linux Kernel.  See below for details.
+
+   o FreeBSD support is not currently being maintained and may not work.
+
+The DRI 3D drivers generally work on systems with Intel or AMD CPUs.  How-
+ever, limited support for Alpha and PowerPC support is underway.
+
+For 3dfx Voodoo hardware, you'll also need the Glide3 runtime library
+(libglide3-v3.so for Voodoo3 or libglide3-v5.so for Voodoo4/5).  These can be
+downloaded from the DRI website.  You can compile them yourself, but it's
+often a painful process.
+
+For Matrox G200/G400, Intel i810/i830 or ATI Rage128/Radeon hardware, you'll
+also need AGP support in your Linux kernel, either built-in or as a loadable
+module.
+
+4.  Linux Kernel Preparation
+
+Only the Linux 2.4.x kernels are currently supported by the DRI hardware
+drivers.  2.5.x kernels may work, but aren't tested.
+
+Most of the DRI drivers require AGP support and using Intel Pentium III SSE
+optimizations also requires an up-to-date Linux kernel.  Configuring your
+kernel correctly is very important, as features such as SSE optimizations
+will be disabled if your kernel does not support them.  Thus, if you have a
+Pentium III processor, you must configure your kernel for the Pentium III
+processor family.
+
+Building a new Linux kernel can be difficult for beginners but there are
+resources on the Internet to help.  This document assumes experience with
+configuring, building and installing Linux kernels.
+
+Linux kernels can be downloaded from www.kernel.org
+
+Here are the basic steps for kernel setup.
+
+   o Download the needed kernel and put it in /usr/src.  Create a directory
+     for the source and unpack it.  For example:
+
+                    cd /usr/src
+                    rm -f linux
+                    mkdir linux-2.4.x
+                    ln -s linux-2.4.x linux
+                    bzcat linux-2.4.x.tar.bz2 | tar xf -
+
+     It is critical that /usr/src/linux point to your new kernel sources,
+     otherwise the kernel headers will not be used when building the DRI.
+     This will almost certainly cause compilation problems.
+
+   o Read /usr/src/linux/Documentation/Changes.  This file lists the minimum
+     requirements for all software packages required to build the kernel.
+     You must upgrade at least gcc, make, binutils and modutils to at least
+     the versions specified in this file.  The other packages may not be
+     needed.  If you are upgrading from Linux 2.2.x you must upgrade your
+     modutils package for Linux 2.4.x.
+
+   o Configure your kernel.  You might, for example, use make menuconfig and
+     do the following:
+
+        o Go to Code maturity level options
+
+        o Enable Prompt for development and/or incomplete code/drivers
+
+        o hit ESC to return to the top-level menu
+
+        o Go to Processor type and features
+
+        o Select your processor type from Processor Family
+
+        o hit ESC to return to the top-level menu
+
+        o Go to Character devices
+
+        o Disable Direct Rendering Manager (XFree86 DRI support) since we'll
+          use the DRI code from the XFree86/DRI tree and will compile it
+          there.
+
+        o Go to /dev/agpgart (AGP Support) (EXPERIMENTAL) (NEW)
+
+        o Hit SPACE twice to build AGP support into the kernel
+
+        o Enable all chipsets' support for AGP
+
+        o It's recommended that you turn on MTRRs under Processor type and
+          Features, but not required.
+
+   o Configure the rest of the kernel as required for your system (i.e. Eth-
+     ernet, SCSI, etc)
+
+   o Exit, saving your kernel configuration.
+
+   o Edit your /etc/lilo.conf file.  Make sure you have an image entry as
+     follows (or similar):
+
+                      image=/boot/vmlinuz
+                            label=linux.2.4.x
+                            read-only
+                            root=/dev/hda1
+
+     The important part is that you have /boot/vmlinuz without a trailing
+     version number.  If this is the first entry in your /etc/lilo.conf AND
+     you haven't set a default, then this will be your default kernel.
+
+   o Compile the new kernel.
+
+                    cd /usr/src/linux-2.4.x
+                    make dep
+                    make bzImage
+                    make modules
+                    make modules_install
+                    make install
+
+     Note that last make command will automatically run lilo for you.
+
+   o Now reboot to use the new kernel.
+
+5.  CPU Architectures
+
+In general, nothing special has to be done to use the DRI on different CPU
+architectures.  There are, however, a few optimizations that are CPU-depen-
+dent.  Mesa will determine at runtime which CPU-dependent optimizations
+should be used and enable them where appropriate.
+
+5.1  Intel Pentium III Features
+
+The Pentium III SSE instructions are used in optimized vertex transformation
+functions in the Mesa-based DRI drivers.  On Linux, SSE requires a recent
+kernel (such as 2.4.0-test11 or later) both at compile time and runtime.
+
+5.2  AMD 3DNow! Features
+
+AMD's 3DNow! instructions are used in optimized vertex transformation func-
+tions in the Mesa-based DRI drivers.  3DNow! is supported in most versions of
+Linux.
+
+5.3  Alpha Features
+
+On newer Alpha processors a significant performance increase can be seen with
+the addition of the -mcpu= option to GCC.  This option is dependent on the
+architecture of the processor.  For example, -mcpu=ev6 will build specifi-
+cally for the EV6 based AXP's, giving both byte and word alignment access to
+the DRI/Mesa drivers.
+
+To enable this optimization edit your xc/config/host.def file and add the
+line:
+
+#define DefaultGcc2AxpOpt -O2 -mcpu=ev6
+
+Additional speed improvements to 3D rendering can be achieved by installing
+Compaq's Math Libraries (CPML) which can be obtained from http://www.sup-
+port.compaq.com/alpha-tools/software/index.html
+
+Once installed, you can add this line to your host.def to build with the CPML
+libraries:
+
+#define UseCompaqMathLibrary YES
+
+The host.def file is explained below.
+
+6.  Downloading the XFree86/DRI CVS Sources
+
+The DRI project is hosted by SourceForge.  The DRI source code, which is a
+subset of the XFree86 source tree, is kept in a CVS repository there.
+
+The DRI CVS sources may be accessed either anonymously or as a registered
+SourceForge user.  It's recommended that you become a registered SourceForge
+user so that you may submit non-anonymous bug reports and can participate in
+the mailing lists.
+
+6.1  Anonymous CVS download:
+
+  1.  Create a directory to store the CVS files:
+
+                       cd ~
+                       mkdir DRI-CVS
+
+      You could put your CVS directory in a different place but we'll use
+      ~/DRI-CVS/ here.
+
+  2.  Check out the CVS sources:
+
+                       cd ~/DRI-CVS
+                       cvs -d:pserver:anonymous@cvs.dri.sourceforge.net:/cvsroot/dri login
+                         (hit ENTER when prompted for a password)
+                       cvs -z3 -d:pserver:anonymous@cvs.dri.sourceforge.net:/cvsroot/dri co xc
+
+      The -z3 flag causes compression to be used in order to reduce the down-
+      load time.
+
+6.2  Registered CVS download:
+
+  1.  Create a directory to store the CVS files:
+
+                       cd ~
+                       mkdir DRI-CVS
+
+      You could put your CVS directory in a different place but we'll use
+      ~/DRI-CVS/ here.
+
+  2.  Set the CVS_RSH environment variable:
+
+                       setenv CVS_RSH ssh      // if using csh or tcsh
+                       export CVS_RSH=ssh      // if using sh or bash
+
+  3.  Check out the CVS sources:
+
+                       cd ~/DRI-CVS
+                       cvs -z3 -d:ext:YOURID@cvs.dri.sourceforge.net:/cvsroot/dri co xc
+
+      Replace YOURID with your CVS login name.  You'll be prompted to enter
+      your sourceforge password.
+
+      The -z3 flag causes compression to be used in order to reduce the down-
+      load time.
+
+6.3  Updating your CVS sources
+
+In the future you'll want to occasionally update your local copy of the DRI
+source code to get the latest changes.  This can be done with:
+
+                cd ~/DRI-CVS
+                cvs -z3 update -dA xc
+
+The -d flag causes any new subdirectories to be created and -A causes most
+recent trunk sources to be fetched, not branch sources.
+
+7.  Mesa
+
+Most of the DRI 3D drivers are based on Mesa (the free implementation of the
+OpenGL API).  The relevant files from Mesa are already included in the
+XFree86/DRI source tree.  There is no need to download or install the Mesa
+source files separately.
+
+Sometimes a newer version of Mesa will be available than the version included
+in XFree86/DRI.  Upgrading Mesa within XFree86/DRI is not always straightfor-
+ward.  It can be an error-prone undertaking, especially for beginners, and is
+not generally recommended.  The DRI developers will upgrade Mesa when appro-
+priate.
+
+8.  Compiling the XFree86/DRI tree
+
+8.1  Make a build tree
+
+Rather than placing object files and library files right in the source tree,
+they're instead put into a parallel build tree.  The build tree is made with
+the lndir command:
+
+                 cd ~/DRI-CVS
+                 ln -s xc XFree40
+                 mkdir build
+                 cd build
+                 lndir -silent -ignorelinks ../XFree40
+
+The build tree will be populated with symbolic links which point back into
+the CVS source tree.
+
+Advanced users may have several build trees for compiling and testing with
+different options.
+
+8.2  Edit the host.def file
+
+The ~/DRI-CVS/build/xc/config/cf/host.def file is used to configure the
+XFree86 build process.  You can change it to customize your build options or
+make adjustments for your particular system configuration
+
+The default host.def file will look something like this:
+
+                 #define DefaultCCOptions -Wall
+     (i386)      #define DefaultGcc2i386Opt -O2
+     (Alpha)     #define DefaultGcc2AxpOpt -O2 -mcpu=ev6 (or similar)
+                 #define LibraryCDebugFlags -O2
+                 #define BuildServersOnly YES
+                 #define XF86CardDrivers vga tdfx mga ati i810
+                 #define LinuxDistribution LinuxRedHat
+                 #define DefaultCCOptions -ansi GccWarningOptions -pipe
+                 #define BuildXF86DRI YES
+                 /* Optionally turn these on for debugging */
+                 /* #define GlxBuiltInTdfx YES */
+                 /* #define GlxBuiltInMga YES */
+                 /* #define GlxBuiltInR128 YES */
+                 /* #define GlxBuiltInRadeon YES */
+                 /* #define DoLoadableServer NO */
+                 #define SharedLibFont NO
+
+The ProjectRoot variable specifies where the XFree86 files will be installed.
+We recommend installing the DRI files over your existing XFree86 installation
+- it's generally safe to do and less error-prone.  This policy is different
+than what we used to recommend.
+
+If XFree86 4.x is not installed in /usr/X11R6/ you'll have to add the follow-
+ing to the host.def file:
+
+                 #define ProjectRoot pathToYourXFree86installation
+
+Note the XF86CardDrivers line to be sure your card's driver is listed.
+
+If you want to enable 3DNow! optimizations in Mesa and the DRI drivers, you
+should add the following:
+
+                 #define MesaUse3DNow YES
+
+You don't have to be using an AMD processor in order to enable this option.
+The DRI will look for 3DNow! support and runtime and only enable it if appli-
+cable.
+
+If you want to enable SSE optimizations in Mesa and the DRI drivers, you must
+upgrade to a Linux 2.4.x kernel.  Mesa will verify that SSE is supported by
+both your processor and your operating system, but to build Mesa inside the
+DRI you need to have the Linux 2.4.x kernel headers in /usr/src/linux.  If
+you enable SSE optimizations with an earlier version of the Linux kernel in
+/usr/src/linux, Mesa will not compile.  You have been warned.  If you do have
+a 2.4.x kernel, you should add the following:
+
+                 #define MesaUseSSE YES
+
+If you want to build the DRM kernel modules as part of the full build pro-
+cess, add the following:
+
+                 #define BuildXF86DRM YES
+
+Otherwise, you'll need to build them separately as described below.
+
+8.3  Compilation
+
+To compile the complete DRI tree:
+
+                 cd ~/DRI-CVS/build/xc/
+                 make World >& world.log
+
+Or if you want to watch the compilation progress:
+
+                 cd ~/DRI-CVS/build/xc/
+                 make World >& world.log &
+                 tail -f world.log
+
+With the default compilation flags it's normal to get a lot of warnings dur-
+ing compilation.
+
+Building will take some time so you may want to go check your email or visit
+slashdot.
+
+WARNING: do not use the -j option with make.  It's reported that it does not
+work with XFree86/DRI.
+
+8.4  Check for compilation errors
+
+Using your text editor, examine world.log for errors by searching for the
+pattern ***.
+
+After fixing the errors, run make World again.  Later, you might just compile
+parts of the source tree but it's important that the whole tree will build
+first.
+
+If you edited your host.def file to enable automatic building of the DRI ker-
+nel module(s), verify that they were built:
+
+               cd ~/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
+               ls
+
+Otherwise, build them now by running
+
+               cd ~/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
+               make -f Makefile.linux
+
+For the 3dfx Voodoo, you should see tdfx.o.  For the Matrox G200/G400, you
+should see mga.o.  For the ATI Rage 128, you should see r128.o.  For the ATI
+Radeon, you should see radeon.o.  For the Intel i810, you should see i810.o.
+
+If the DRI kernel module(s) failed to build you should verify that you're
+using the right version of the Linux kernel.  The most recent kernels are not
+always supported.
+
+If your build machine is running a different version of the kernel than your
+target machine (i.e. 2.2.x vs. 2.4.x), make will select the wrong kernel
+source tree. This can be fixed by explicitly setting the value of LINUXDIR.
+If the path to your kernel source is /usr/src/linux-2.4.x,
+
+               cd ~/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
+               make -f Makefile.linux LINUXDIR=/usr/src/linux-2.4.x
+
+or alternatively, edit Makefile.linux to set LINUXDIR before the ifndef LIN-
+UXDIR line.
+
+8.5  DRI kernel module installation
+
+The DRI kernel modules will be in ~/DRI-CVS/build/xc/pro-
+grams/Xserver/hw/xfree86/os-support/linux/drm/kernel/.
+
+To load the appropriate DRM module in your running kernel you can either use
+ismod and restart your X server or copy the kernel module to /lib/mod-
+ules/2.4.x/kernel/drivers/char/drm/ then run depmod and restart your X
+server.
+
+Make sure you first unload any older DRI kernel modules that might be already
+loaded.
+
+Note that some DRM modules require that the agpgart module be loaded first.
+
+9.  Normal Installation and Configuration
+
+Most users will want to install the new X server and use it in place of their
+old X server.  This section explains how to do that.
+
+Developers, on the other hand, may just want to test the X server without
+actually installing it as their default server.  If you want to do that, skip
+to the next section.
+
+9.1  Installation
+
+Here are the installation commands:
+
+                su
+                cd ~/DRI-CVS/build/xc
+                make install
+
+9.2  Update the XF86Config File
+
+You may need to edit your XF86Config file to enable the DRI.  The config file
+is usually installed as /etc/X11/XF86Config-4.  See the DRI User Guide for
+details, but basically, you need to load the "glx" and "dri" modules and add
+a "DRI" section.
+
+On the DRI web site, in the resources section, you'll find example XF86Config
+files for a number of graphics cards.  These configuration files also setup
+DRI options so it's highly recommended that you look at these examples.
+
+The XFree86 4.x server can generate a basic configuration file itself.  Sim-
+ply do this:
+
+                  cd /usr/X11R6/bin
+                  ./XFree86 -configure
+
+A file named /root/XF86Config.new will be created.  It should allow you to
+try your X server but you'll almost certainly have to edit it.  For example,
+you should add HorizSync and VertRefresh options to the Monitor section and
+Modes options to the Screen section.  Also, the ModulePath option in the
+Files section should be set to /usr/X11R6/lib/modules.
+
+9.3  Start the New X Server
+
+The new X server should be ready to use now.  Start your X server in your
+usual manner.  Often times the startx command is used:
+
+                  startx
+
+10.  Testing the Server Without Installing It
+
+As mentioned at the start of section 9, developers may want to simply run the
+X server without installing it.  This can save some time and allow you to
+keep a number of X servers available for testing.
+
+10.1  Configuration
+
+As described in the preceding section, you'll need to create a configuration
+file for the new server.  Put the XF86Config file in your ~/DRI-
+CVS/build/xc/programs/Xserver directory.
+
+Be sure the ModulePath option in your XF86Config file is set correctly.
+
+10.2  A Startup Script
+
+A simple shell script can be used to start the X server.  Here's an example.
+
+             #!/bin/sh
+             export DISPLAY=:0
+             ./XFree86 -xf86config XF86Config & \
+             sleep 2
+             fvwm2 &
+             xset b off
+             xmodmap -e "clear mod4"
+             xsetroot -solid "#00306f"
+             xterm -geometry 80x40+0+0
+
+You might name this script start-dri.  Put it in your ~/DRI-CVS/build/xc/pro-
+grams/Xserver directory.
+
+To test the server run the script:
+
+                  cd ~/DRI-CVS/build/xc/programs/Xserver
+                  ./start-dri
+
+For debugging, you may also want to capture the log messages printed by the
+server in a file.  If you're using the C-shell:
+
+                  ./start-dri >& log
+
+11.  Where To Go From Here
+
+At this point your X server should be up and running with hardware-acceler-
+ated direct rendering.  Please read the DRI User Guide for information about
+trouble shooting and how to use the DRI-enabled X server for 3D applications.
+
+     Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/DRIcomp.sgml,v 1.19 dawes Exp $
diff --git a/xorg-server/hw/xfree86/doc/README.modes b/xorg-server/hw/xfree86/doc/README.modes
index 894e21313..da9d41eb5 100644
--- a/xorg-server/hw/xfree86/doc/README.modes
+++ b/xorg-server/hw/xfree86/doc/README.modes
@@ -1,474 +1,474 @@
-		    Multi-monitor Mode Setting APIs
-	           Keith Packard, <keithp@keithp.com
-		   	   6 March 2007
-
-1. Introduction
-
-This document describes a set of mode setting APIs added in X server version
-1.3 that support multiple monitors per card. These interfaces expose the
-underlying hardware CRTC and output concepts to the xf86 DDX layer so that
-the implementation of initial server setup and mode changes through
-extensions can be shared across drivers. In addition, these new interfaces
-support a new configuration mechanism as well which allows each monitor to
-be customized separately providing a consistent cross-driver configuration
-mechanism that supports the full range of output features.
-
-All of the code implementing this interface can be found in hw/xfree86/modes
-in the X server sources.
-
-2. Overview
-
-This document describes both the driver API and the configuration data
-placed in xorg.conf; these are entirely separate as the driver has no
-interaction with the configuration information at all. Much of the structure
-here is cloned from the RandR extension version 1.2 additions which deal
-with the same kinds of information.
-
-2.1 API overview
-
-The mode setting API is expressed through two new driver-visible objects,
-the 'CRTC' (xf86CrtcRec) and the 'Output' (xf86OutputRec). A CRTC refers to
-hardware within the video system that can scan a subset of the framebuffer
-and generate a video signal. An Output receives that signal and transmits it
-to a monitor, projector or other device.
-
-The xf86CrtcRec and xf86OutputRec contain a small amount of state data
-related to the object along with a pointer to a set of functions provided by
-the driver that manipulate the object in fairly simple ways.
-
-To emulate older behaviour, one of the outputs is picked as the 'compat'
-output; this output changes over time as outputs are detected and used, the
-goal is to always have one 'special' output which is used for operations
-which need a single defined monitor (like XFree86-VidModeExtension mode
-setting, RandR 1.1 mode setting, DDC property setting, etc.).
-
-2.1.1 Output overview 
-
-As outputs are connected to monitors, they hold a list of modes supported by
-the monitor. If the monitor and output support DDC, then the list of modes
-generally comes from the EDID data in the monitor. Otherwise, the server
-uses the standard VESA modes, pruned by monitor timing. If the configuration
-file doesn't contain monitor timing data, the server uses default timing
-information which supports 640x480, 800x600 and 1024x768 all with a 60Hz
-refresh rate.
-
-As hardware often limits possible configuration combinations, each output
-knows the set of CRTCs that it can be connected to as well as the set of
-other outputs which can be simutaneously connected to a CRTC.
-
-2.1.2 CRTC overview
-
-CRTCs serve only to stream frame buffer data to outputs using a mode line.
-Ideally, they would not be presented to the user at all, and in fact the
-configuration file doesn't expose them. The RandR 1.2 protocol does, but the
-hope there is that client-side applications will hide them carefully away.
-
-Each crtc has an associated cursor, along with the current configuration.
-All of the data needed to determine valid configurations is contained within
-the Outputs.
-
-2.2 Configuration overview
-
-As outputs drive monitors, the "Monitor" section has been repurposed to
-define their configuration. This provides for a bit more syntax than
-the large list of driver-specific options that were used in the past for
-similar configuration.
-
-However, the existing "Monitor" section referenced by the active "Screen"
-section no longer has any use at all; some sensible meaning for this
-parameter is needed now that a Screen can have multiple Monitors.
-
-3. Public Functions
-
-3.1 PreInit functions
-
-These functions should be used during the driver PreInit phase, they are
-arranged in the order they should be invoked.
-
-    void
-    xf86CrtcConfigInit (ScrnInfoPtr			scrn
-			const xf86CrtcConfigFuncsRec	*funcs)
-
-This function allocates and initializes structures needed to track CRTC and
-Output state.
-
-    void
-    xf86CrtcSetSizeRange (ScrnInfoPtr scrn,
-			  int minWidth, int minHeight,
-			  int maxWidth, int maxHeight)
-
-This sets the range of screen sizes supported by the driver.
-
-    xf86CrtcPtr
-    xf86CrtcCreate (ScrnInfoPtr             scrn,
-		    const xf86CrtcFuncsRec  *funcs)
-    
-Create one CRTC object. See the discussion below for a description of the
-contents of the xf86CrtcFuncsRec. Note that this is done in PreInit, so it
-should not be re-invoked at each server generation. Create one of these for
-each CRTC present in the hardware.
-    
-    xf86OutputPtr
-    xf86OutputCreate (ScrnInfoPtr              scrn,
-		      const xf86OutputFuncsRec *funcs,
-		      const char	       *name)
-
-Create one Output object. See the discussion below for a description of the
-contents of the xf86OutputFuncsRec. This is also called from PreInit and
-need not be re-invoked at each ScreenInit time. An Output should be created
-for every Output present in the hardware, not just for outputs which have
-detected monitors.
-    
-    Bool
-    xf86OutputRename (xf86OutputPtr output, const char *name)
-
-If necessary, the name of an output can be changed after it is created using
-this function.
-    
-    Bool
-    xf86InitialConfiguration (ScrnInfoPtr scrn, Bool canGrow)
-
-Using the resources provided, and the configuration specified by the user,
-this function computes an initial configuration for the server. It tries to
-enable as much hardware as possible using some fairly simple heuristics. 
-
-The 'canGrow' parameter indicates that the frame buffer does not have a fixed
-size (fixed size frame buffers are required by XAA). When the frame buffer
-has a fixed size, the configuration selects a 'reasonablely large' frame
-buffer so that common reconfiguration options are possible. For resizable
-frame buffers, the frame buffer is set to the smallest size that encloses
-the desired configuration.
-    
-3.2 ScreenInit functions
-
-These functions should be used during the driver ScreenInit phase.
-
-    Bool
-    xf86DiDGAInit (ScreenPtr screen, unsigned long dga_address)
-
-This function provides driver-independent accelerated DGA support for some
-of the DGA operations; using this, the driver can avoid needing to implement
-any of the rest of DGA.
-
-    Bool
-    xf86SaveScreen(ScreenPtr pScreen, int mode)
-
-Stick this in pScreen->SaveScreen and the core X screen saver will be
-implemented by disabling outputs and crtcs using their dpms functions.
-
-    void
-    xf86DPMSSet(ScrnInfoPtr scrn, int mode, int flags)
-
-Pass this function to xf86DPMSInit and all DPMS mode switching will be
-managed by using the dpms functions provided by the Outputs and CRTCs.
-
-    Bool
-    xf86CrtcScreenInit (ScreenPtr screen)
-
-This function completes the screen initialization process for the crtc and
-output objects. Call it near the end of the ScreenInit function, after the
-frame buffer and acceleration layers have been added.
-
-3.3 EnterVT functions
-
-Functions used during EnterVT, or whenever the current configuration needs
-to be applied to the hardware.
-
-    Bool
-    xf86SetDesiredModes (ScrnInfoPtr scrn)
-
-xf86InitialConfiguration selects the desired configuration at PreInit time;
-when the server finally hits ScreenInit, xf86SetDesiredModes is used by the
-driver to take that configuration and apply it to the hardware. In addition,
-successful mode selection at other times updates the configuration that will
-be used by this function, so LeaveVT/EnterVT pairs can simply invoke this
-and return to the previous configuration.
-
-3.4 SwitchMode functions
-
-Functions called from the pScrn->SwitchMode hook, which is used by the
-XFree86-VidModeExtension and the keypad mode switch commands.
-
-    Bool
-    xf86SetSingleMode (ScrnInfoPtr	scrn, 
-		       DisplayModePtr   desired,
-		       Rotation		rotation)
-
-This function applies the specified mode to all active outputs. Which is to
-say, it picks reasonable modes for all active outputs, attempting to get the
-screen to the specified size while not breaking anything that is currently
-working.
-
-3.7 get_modes functions
-
-Functions called during output->get_modes to help build lists of modes
-
-    xf86MonPtr
-    xf86OutputGetEDID (xf86OutputPtr output, I2CBusPtr pDDCBus)
-
-This returns the EDID data structure for the 'output' using the I2C bus
-'pDDCBus'. This has no effect on 'output' itself.
-
-    void
-    xf86OutputSetEDID (xf86OutputPtr output, xf86MonPtr edid_mon)
-
-Once the EDID data has been fetched, this call applies the EDID data to the
-output object, setting the physical size and also various properties, like
-the DDC root window property (when output is the 'compat' output), and the
-RandR 1.2 EDID output properties.
-
-    DisplayModePtr
-    xf86OutputGetEDIDModes (xf86OutputPtr output)
-
-Given an EDID data structure, this function computes a list of suitable
-modes. This function also applies a sequence of 'quirks' during this process
-so that the returned modes may not actually match the mode data present in
-the EDID data.
-
-3.6 Other functions
-
-These remaining functions in the API can be used by the driver as needed.
-
-    Bool
-    xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode, Rotation rotation,
-		     int x, int y)
-
-Applies a mode to a CRTC. All of the outputs which are currently using the
-specified CRTC are included in the mode setting process. 'x' and 'y' are the
-offset within the frame buffer that the crtc is placed at. No checking is
-done in this function to ensure that the mode is usable by the active
-outputs.
-    
-    void
-    xf86ProbeOutputModes (ScrnInfoPtr pScrn, int maxX, int maxY)
-
-This discards the mode lists for all outputs, re-detects monitor presence
-and then acquires new mode lists for all monitors which are not disconnected.
-Monitor configuration data is used to modify the mode lists returned by the
-outputs. 'maxX' and 'maxY' limit the maximum size modes that will be
-returned.
-    
-    void
-    xf86SetScrnInfoModes (ScrnInfoPtr pScrn)
-
-This copies the 'compat' output mode list into the pScrn modes list which is
-used by the XFree86-VidModeExtension and the keypad mode switching
-operations. The current 'desired' mode for the CRTC associated with the
-'compat' output is placed first in this list to indicate the current mode.
-Usually, the driver won't need to call this function as
-xf86InitialConfiguration will do so automatically, as well as any RandR
-functions which reprobe for modes. However, if the driver reprobes for modes
-at other times using xf86ProbeOutputModes, this function needs to be called.
-    
-    Bool
-    xf86DiDGAReInit (ScreenPtr pScreen)
-
-This is similar to xf86SetScrnInfoModes, but it applies the 'compat' output
-mode list to the set of modes advertised by the DGA extension; it needs to
-be called whenever xf86ProbeOutputModes is invoked.
-
-    void
-    xf86DisableUnusedFunctions(ScrnInfoPtr pScrn)
-
-After any sequence of calls using xf86CrtcSetMode, this function cleans up
-any leftover Output and CRTC objects by disabling them, saving power. It is
-safe to call this whenever the server is running as it only disables objects
-which are not currently in use.
-    
-4. CRTC operations
-
-4.1 CRTC functions
-
-These functions provide an abstract interface for the CRTC object; most
-manipulation of the CRTC object is done through these functions.
-
-    void
-    crtc->funcs->dpms (xf86CrtcPtr crtc, int mode)
-
-Where 'mode' is one of DPMSModeOff, DPMSModeSuspend, DPMSModeStandby or
-DPMSModeOn. This requests that the crtc go to the specified power state.
-When changing power states, the output dpms functions are invoked before the
-crtc dpms functions.
-
-    void
-    crtc->funcs->save (xf86CrtcPtr crtc)
-	
-    void
-    crtc->funcs->restore (xf86CrtcPtr crtc)
-
-Preserve/restore any register contents related to the CRTC. These are
-strictly a convenience for the driver writer; if the existing driver has
-fully operation save/restore functions, you need not place any additional
-code here. In particular, the server itself never uses this function.
-
-    Bool
-    crtc->funcs->lock (xf86CrtcPtr crtc)
-	
-    void
-    crtc->funcs->unlock (xf86CrtcPtr crtc)
-
-These functions are invoked around mode setting operations; the intent is
-that DRI locking be done here to prevent DRI applications from manipulating
-the hardware while the server is busy changing the output configuration. If
-the lock function returns FALSE, the unlock function will not be invoked.
-
-    Bool
-    crtc->funcs->mode_fixup (xf86CrtcPtr crtc, 
-			     DisplayModePtr mode,
-			     DisplayModePtr adjusted_mode)
-
-This call gives the CRTC a chance to see what mode will be set and to
-comment on the mode by changing 'adjusted_mode' as needed. This function
-shall not modify the state of the crtc hardware at all. If the CRTC cannot
-accept this mode, this function may return FALSE.
-
-    void
-    crtc->funcs->prepare (xf86CrtcPtr crtc)
-
-This call is made just before the mode is set to make the hardware ready for
-the operation. A usual function to perform here is to disable the crtc so
-that mode setting can occur with clocks turned off and outputs deactivated.
-
-    void
-    crtc->funcs->mode_set (xf86CrtcPtr crtc,
-			   DisplayModePtr mode,
-			   DisplayModePtr adjusted_mode)
-
-This function applies the specified mode (possibly adjusted by the CRTC
-and/or Outputs).
-
-    void
-    crtc->funcs->commit (xf86CrtcPtr crtc)
-
-Once the mode has been applied to the CRTC and Outputs, this function is
-invoked to let the hardware turn things back on.
-
-    void
-    crtc->funcs->gamma_set (xf86CrtcPtr crtc, CARD16 *red,
-			    CARD16 *green, CARD16 *blue, int size)
-
-This function adjusts the gamma ramps for the specified crtc.
-
-    void *
-    crtc->funcs->shadow_allocate (xf86CrtcPtr crtc, int width, int height)
-
-This function allocates frame buffer space for a shadow frame buffer. When
-allocated, the crtc must scan from the shadow instead of the main frame
-buffer. This is used for rotation. The address returned is passed to the
-shadow_create function. This function should return NULL on failure.
-
-    PixmapPtr
-    crtc->funcs->shadow_create (xf86CrtcPtr crtc, void *data,
-				int width, int height)
-
-This function creates a pixmap object that will be used as a shadow of the
-main frame buffer for CRTCs which are rotated or reflected. 'data' is the
-value returned by shadow_allocate.
-
-    void
-    crtc->funcs->shadow_destroy (xf86CrtcPtr crtc, PixmapPtr pPixmap,
-				 void *data)
-
-Destroys any associated shadow objects. If pPixmap is NULL, then a pixmap
-was not created, but 'data' may still be non-NULL indicating that the shadow
-had been allocated.
-
-    void
-    crtc->funcs->destroy (xf86CrtcPtr crtc)
-
-When a CRTC is destroyed (which only happens in error cases), this function
-can clean up any driver-specific data.
-
-4.2 CRTC fields
-
-The CRTC object is not opaque; there are several fields of interest to the
-driver writer.
-
-    struct _xf86Crtc {
-	/**
-	 * Associated ScrnInfo
-	 */
-	ScrnInfoPtr     scrn;
-    
-	/**
-	 * Active state of this CRTC
-	 *
-	 * Set when this CRTC is driving one or more outputs
-	 */
-	Bool            enabled;
-    
-	/** Track whether cursor is within CRTC range  */
-	Bool            cursorInRange;
-    
-	/** Track state of cursor associated with this CRTC */
-	Bool            cursorShown;
-    
-	/**
-	 * Active mode
-	 *
-	 * This reflects the mode as set in the CRTC currently
-	 * It will be cleared when the VT is not active or
-	 * during server startup
-	 */
-	DisplayModeRec  mode;
-	Rotation        rotation;
-	PixmapPtr       rotatedPixmap;
-	void            *rotatedData;
-    
-	/**
-	 * Position on screen
-	 *
-	 * Locates this CRTC within the frame buffer
-	 */
-	int             x, y;
-    
-	/**
-	 * Desired mode
-	 *
-	 * This is set to the requested mode, independent of
-	 * whether the VT is active. In particular, it receives
-	 * the startup configured mode and saves the active mode
-	 * on VT switch.
-	 */
-	DisplayModeRec  desiredMode;
-	Rotation        desiredRotation;
-	int             desiredX, desiredY;
-    
-	/** crtc-specific functions */
-	const xf86CrtcFuncsRec *funcs;
-    
-	/**
-	 * Driver private
-	 *
-	 * Holds driver-private information
-	 */
-	void            *driver_private;
-    #ifdef RANDR_12_INTERFACE
-	/**
-	 * RandR crtc
-	 *
-	 * When RandR 1.2 is available, this
-	 * points at the associated crtc object
-	 */
-	RRCrtcPtr       randr_crtc;
-    #else
-	void            *randr_crtc;
-    #endif
-    };
-
-    
-5. Output functions.
-
-6. Configuration
-
-Because the configuration file syntax is fixed,
-this was done by creating new "Driver" section options that hook specific
-outputs to specific "Monitor" sections in the file. The option:
-section of the form:
-
-	Option	"monitor-VGA" "My VGA Monitor"
-
-connects the VGA output of this driver to the "Monitor" section with
-Identifier "My VGA Monitor". All of the usual monitor options can now be
-placed in that "Monitor" section and will be applied to the VGA output
-configuration.
+		    Multi-monitor Mode Setting APIs

+	           Keith Packard, <keithp@keithp.com

+		   	   6 March 2007

+

+1. Introduction

+

+This document describes a set of mode setting APIs added in X server version

+1.3 that support multiple monitors per card. These interfaces expose the

+underlying hardware CRTC and output concepts to the xf86 DDX layer so that

+the implementation of initial server setup and mode changes through

+extensions can be shared across drivers. In addition, these new interfaces

+support a new configuration mechanism as well which allows each monitor to

+be customized separately providing a consistent cross-driver configuration

+mechanism that supports the full range of output features.

+

+All of the code implementing this interface can be found in hw/xfree86/modes

+in the X server sources.

+

+2. Overview

+

+This document describes both the driver API and the configuration data

+placed in xorg.conf; these are entirely separate as the driver has no

+interaction with the configuration information at all. Much of the structure

+here is cloned from the RandR extension version 1.2 additions which deal

+with the same kinds of information.

+

+2.1 API overview

+

+The mode setting API is expressed through two new driver-visible objects,

+the 'CRTC' (xf86CrtcRec) and the 'Output' (xf86OutputRec). A CRTC refers to

+hardware within the video system that can scan a subset of the framebuffer

+and generate a video signal. An Output receives that signal and transmits it

+to a monitor, projector or other device.

+

+The xf86CrtcRec and xf86OutputRec contain a small amount of state data

+related to the object along with a pointer to a set of functions provided by

+the driver that manipulate the object in fairly simple ways.

+

+To emulate older behaviour, one of the outputs is picked as the 'compat'

+output; this output changes over time as outputs are detected and used, the

+goal is to always have one 'special' output which is used for operations

+which need a single defined monitor (like XFree86-VidModeExtension mode

+setting, RandR 1.1 mode setting, DDC property setting, etc.).

+

+2.1.1 Output overview 

+

+As outputs are connected to monitors, they hold a list of modes supported by

+the monitor. If the monitor and output support DDC, then the list of modes

+generally comes from the EDID data in the monitor. Otherwise, the server

+uses the standard VESA modes, pruned by monitor timing. If the configuration

+file doesn't contain monitor timing data, the server uses default timing

+information which supports 640x480, 800x600 and 1024x768 all with a 60Hz

+refresh rate.

+

+As hardware often limits possible configuration combinations, each output

+knows the set of CRTCs that it can be connected to as well as the set of

+other outputs which can be simutaneously connected to a CRTC.

+

+2.1.2 CRTC overview

+

+CRTCs serve only to stream frame buffer data to outputs using a mode line.

+Ideally, they would not be presented to the user at all, and in fact the

+configuration file doesn't expose them. The RandR 1.2 protocol does, but the

+hope there is that client-side applications will hide them carefully away.

+

+Each crtc has an associated cursor, along with the current configuration.

+All of the data needed to determine valid configurations is contained within

+the Outputs.

+

+2.2 Configuration overview

+

+As outputs drive monitors, the "Monitor" section has been repurposed to

+define their configuration. This provides for a bit more syntax than

+the large list of driver-specific options that were used in the past for

+similar configuration.

+

+However, the existing "Monitor" section referenced by the active "Screen"

+section no longer has any use at all; some sensible meaning for this

+parameter is needed now that a Screen can have multiple Monitors.

+

+3. Public Functions

+

+3.1 PreInit functions

+

+These functions should be used during the driver PreInit phase, they are

+arranged in the order they should be invoked.

+

+    void

+    xf86CrtcConfigInit (ScrnInfoPtr			scrn

+			const xf86CrtcConfigFuncsRec	*funcs)

+

+This function allocates and initializes structures needed to track CRTC and

+Output state.

+

+    void

+    xf86CrtcSetSizeRange (ScrnInfoPtr scrn,

+			  int minWidth, int minHeight,

+			  int maxWidth, int maxHeight)

+

+This sets the range of screen sizes supported by the driver.

+

+    xf86CrtcPtr

+    xf86CrtcCreate (ScrnInfoPtr             scrn,

+		    const xf86CrtcFuncsRec  *funcs)

+    

+Create one CRTC object. See the discussion below for a description of the

+contents of the xf86CrtcFuncsRec. Note that this is done in PreInit, so it

+should not be re-invoked at each server generation. Create one of these for

+each CRTC present in the hardware.

+    

+    xf86OutputPtr

+    xf86OutputCreate (ScrnInfoPtr              scrn,

+		      const xf86OutputFuncsRec *funcs,

+		      const char	       *name)

+

+Create one Output object. See the discussion below for a description of the

+contents of the xf86OutputFuncsRec. This is also called from PreInit and

+need not be re-invoked at each ScreenInit time. An Output should be created

+for every Output present in the hardware, not just for outputs which have

+detected monitors.

+    

+    Bool

+    xf86OutputRename (xf86OutputPtr output, const char *name)

+

+If necessary, the name of an output can be changed after it is created using

+this function.

+    

+    Bool

+    xf86InitialConfiguration (ScrnInfoPtr scrn, Bool canGrow)

+

+Using the resources provided, and the configuration specified by the user,

+this function computes an initial configuration for the server. It tries to

+enable as much hardware as possible using some fairly simple heuristics. 

+

+The 'canGrow' parameter indicates that the frame buffer does not have a fixed

+size (fixed size frame buffers are required by XAA). When the frame buffer

+has a fixed size, the configuration selects a 'reasonablely large' frame

+buffer so that common reconfiguration options are possible. For resizable

+frame buffers, the frame buffer is set to the smallest size that encloses

+the desired configuration.

+    

+3.2 ScreenInit functions

+

+These functions should be used during the driver ScreenInit phase.

+

+    Bool

+    xf86DiDGAInit (ScreenPtr screen, unsigned long dga_address)

+

+This function provides driver-independent accelerated DGA support for some

+of the DGA operations; using this, the driver can avoid needing to implement

+any of the rest of DGA.

+

+    Bool

+    xf86SaveScreen(ScreenPtr pScreen, int mode)

+

+Stick this in pScreen->SaveScreen and the core X screen saver will be

+implemented by disabling outputs and crtcs using their dpms functions.

+

+    void

+    xf86DPMSSet(ScrnInfoPtr scrn, int mode, int flags)

+

+Pass this function to xf86DPMSInit and all DPMS mode switching will be

+managed by using the dpms functions provided by the Outputs and CRTCs.

+

+    Bool

+    xf86CrtcScreenInit (ScreenPtr screen)

+

+This function completes the screen initialization process for the crtc and

+output objects. Call it near the end of the ScreenInit function, after the

+frame buffer and acceleration layers have been added.

+

+3.3 EnterVT functions

+

+Functions used during EnterVT, or whenever the current configuration needs

+to be applied to the hardware.

+

+    Bool

+    xf86SetDesiredModes (ScrnInfoPtr scrn)

+

+xf86InitialConfiguration selects the desired configuration at PreInit time;

+when the server finally hits ScreenInit, xf86SetDesiredModes is used by the

+driver to take that configuration and apply it to the hardware. In addition,

+successful mode selection at other times updates the configuration that will

+be used by this function, so LeaveVT/EnterVT pairs can simply invoke this

+and return to the previous configuration.

+

+3.4 SwitchMode functions

+

+Functions called from the pScrn->SwitchMode hook, which is used by the

+XFree86-VidModeExtension and the keypad mode switch commands.

+

+    Bool

+    xf86SetSingleMode (ScrnInfoPtr	scrn, 

+		       DisplayModePtr   desired,

+		       Rotation		rotation)

+

+This function applies the specified mode to all active outputs. Which is to

+say, it picks reasonable modes for all active outputs, attempting to get the

+screen to the specified size while not breaking anything that is currently

+working.

+

+3.7 get_modes functions

+

+Functions called during output->get_modes to help build lists of modes

+

+    xf86MonPtr

+    xf86OutputGetEDID (xf86OutputPtr output, I2CBusPtr pDDCBus)

+

+This returns the EDID data structure for the 'output' using the I2C bus

+'pDDCBus'. This has no effect on 'output' itself.

+

+    void

+    xf86OutputSetEDID (xf86OutputPtr output, xf86MonPtr edid_mon)

+

+Once the EDID data has been fetched, this call applies the EDID data to the

+output object, setting the physical size and also various properties, like

+the DDC root window property (when output is the 'compat' output), and the

+RandR 1.2 EDID output properties.

+

+    DisplayModePtr

+    xf86OutputGetEDIDModes (xf86OutputPtr output)

+

+Given an EDID data structure, this function computes a list of suitable

+modes. This function also applies a sequence of 'quirks' during this process

+so that the returned modes may not actually match the mode data present in

+the EDID data.

+

+3.6 Other functions

+

+These remaining functions in the API can be used by the driver as needed.

+

+    Bool

+    xf86CrtcSetMode (xf86CrtcPtr crtc, DisplayModePtr mode, Rotation rotation,

+		     int x, int y)

+

+Applies a mode to a CRTC. All of the outputs which are currently using the

+specified CRTC are included in the mode setting process. 'x' and 'y' are the

+offset within the frame buffer that the crtc is placed at. No checking is

+done in this function to ensure that the mode is usable by the active

+outputs.

+    

+    void

+    xf86ProbeOutputModes (ScrnInfoPtr pScrn, int maxX, int maxY)

+

+This discards the mode lists for all outputs, re-detects monitor presence

+and then acquires new mode lists for all monitors which are not disconnected.

+Monitor configuration data is used to modify the mode lists returned by the

+outputs. 'maxX' and 'maxY' limit the maximum size modes that will be

+returned.

+    

+    void

+    xf86SetScrnInfoModes (ScrnInfoPtr pScrn)

+

+This copies the 'compat' output mode list into the pScrn modes list which is

+used by the XFree86-VidModeExtension and the keypad mode switching

+operations. The current 'desired' mode for the CRTC associated with the

+'compat' output is placed first in this list to indicate the current mode.

+Usually, the driver won't need to call this function as

+xf86InitialConfiguration will do so automatically, as well as any RandR

+functions which reprobe for modes. However, if the driver reprobes for modes

+at other times using xf86ProbeOutputModes, this function needs to be called.

+    

+    Bool

+    xf86DiDGAReInit (ScreenPtr pScreen)

+

+This is similar to xf86SetScrnInfoModes, but it applies the 'compat' output

+mode list to the set of modes advertised by the DGA extension; it needs to

+be called whenever xf86ProbeOutputModes is invoked.

+

+    void

+    xf86DisableUnusedFunctions(ScrnInfoPtr pScrn)

+

+After any sequence of calls using xf86CrtcSetMode, this function cleans up

+any leftover Output and CRTC objects by disabling them, saving power. It is

+safe to call this whenever the server is running as it only disables objects

+which are not currently in use.

+    

+4. CRTC operations

+

+4.1 CRTC functions

+

+These functions provide an abstract interface for the CRTC object; most

+manipulation of the CRTC object is done through these functions.

+

+    void

+    crtc->funcs->dpms (xf86CrtcPtr crtc, int mode)

+

+Where 'mode' is one of DPMSModeOff, DPMSModeSuspend, DPMSModeStandby or

+DPMSModeOn. This requests that the crtc go to the specified power state.

+When changing power states, the output dpms functions are invoked before the

+crtc dpms functions.

+

+    void

+    crtc->funcs->save (xf86CrtcPtr crtc)

+	

+    void

+    crtc->funcs->restore (xf86CrtcPtr crtc)

+

+Preserve/restore any register contents related to the CRTC. These are

+strictly a convenience for the driver writer; if the existing driver has

+fully operation save/restore functions, you need not place any additional

+code here. In particular, the server itself never uses this function.

+

+    Bool

+    crtc->funcs->lock (xf86CrtcPtr crtc)

+	

+    void

+    crtc->funcs->unlock (xf86CrtcPtr crtc)

+

+These functions are invoked around mode setting operations; the intent is

+that DRI locking be done here to prevent DRI applications from manipulating

+the hardware while the server is busy changing the output configuration. If

+the lock function returns FALSE, the unlock function will not be invoked.

+

+    Bool

+    crtc->funcs->mode_fixup (xf86CrtcPtr crtc, 

+			     DisplayModePtr mode,

+			     DisplayModePtr adjusted_mode)

+

+This call gives the CRTC a chance to see what mode will be set and to

+comment on the mode by changing 'adjusted_mode' as needed. This function

+shall not modify the state of the crtc hardware at all. If the CRTC cannot

+accept this mode, this function may return FALSE.

+

+    void

+    crtc->funcs->prepare (xf86CrtcPtr crtc)

+

+This call is made just before the mode is set to make the hardware ready for

+the operation. A usual function to perform here is to disable the crtc so

+that mode setting can occur with clocks turned off and outputs deactivated.

+

+    void

+    crtc->funcs->mode_set (xf86CrtcPtr crtc,

+			   DisplayModePtr mode,

+			   DisplayModePtr adjusted_mode)

+

+This function applies the specified mode (possibly adjusted by the CRTC

+and/or Outputs).

+

+    void

+    crtc->funcs->commit (xf86CrtcPtr crtc)

+

+Once the mode has been applied to the CRTC and Outputs, this function is

+invoked to let the hardware turn things back on.

+

+    void

+    crtc->funcs->gamma_set (xf86CrtcPtr crtc, CARD16 *red,

+			    CARD16 *green, CARD16 *blue, int size)

+

+This function adjusts the gamma ramps for the specified crtc.

+

+    void *

+    crtc->funcs->shadow_allocate (xf86CrtcPtr crtc, int width, int height)

+

+This function allocates frame buffer space for a shadow frame buffer. When

+allocated, the crtc must scan from the shadow instead of the main frame

+buffer. This is used for rotation. The address returned is passed to the

+shadow_create function. This function should return NULL on failure.

+

+    PixmapPtr

+    crtc->funcs->shadow_create (xf86CrtcPtr crtc, void *data,

+				int width, int height)

+

+This function creates a pixmap object that will be used as a shadow of the

+main frame buffer for CRTCs which are rotated or reflected. 'data' is the

+value returned by shadow_allocate.

+

+    void

+    crtc->funcs->shadow_destroy (xf86CrtcPtr crtc, PixmapPtr pPixmap,

+				 void *data)

+

+Destroys any associated shadow objects. If pPixmap is NULL, then a pixmap

+was not created, but 'data' may still be non-NULL indicating that the shadow

+had been allocated.

+

+    void

+    crtc->funcs->destroy (xf86CrtcPtr crtc)

+

+When a CRTC is destroyed (which only happens in error cases), this function

+can clean up any driver-specific data.

+

+4.2 CRTC fields

+

+The CRTC object is not opaque; there are several fields of interest to the

+driver writer.

+

+    struct _xf86Crtc {

+	/**

+	 * Associated ScrnInfo

+	 */

+	ScrnInfoPtr     scrn;

+    

+	/**

+	 * Active state of this CRTC

+	 *

+	 * Set when this CRTC is driving one or more outputs

+	 */

+	Bool            enabled;

+    

+	/** Track whether cursor is within CRTC range  */

+	Bool            cursorInRange;

+    

+	/** Track state of cursor associated with this CRTC */

+	Bool            cursorShown;

+    

+	/**

+	 * Active mode

+	 *

+	 * This reflects the mode as set in the CRTC currently

+	 * It will be cleared when the VT is not active or

+	 * during server startup

+	 */

+	DisplayModeRec  mode;

+	Rotation        rotation;

+	PixmapPtr       rotatedPixmap;

+	void            *rotatedData;

+    

+	/**

+	 * Position on screen

+	 *

+	 * Locates this CRTC within the frame buffer

+	 */

+	int             x, y;

+    

+	/**

+	 * Desired mode

+	 *

+	 * This is set to the requested mode, independent of

+	 * whether the VT is active. In particular, it receives

+	 * the startup configured mode and saves the active mode

+	 * on VT switch.

+	 */

+	DisplayModeRec  desiredMode;

+	Rotation        desiredRotation;

+	int             desiredX, desiredY;

+    

+	/** crtc-specific functions */

+	const xf86CrtcFuncsRec *funcs;

+    

+	/**

+	 * Driver private

+	 *

+	 * Holds driver-private information

+	 */

+	void            *driver_private;

+    #ifdef RANDR_12_INTERFACE

+	/**

+	 * RandR crtc

+	 *

+	 * When RandR 1.2 is available, this

+	 * points at the associated crtc object

+	 */

+	RRCrtcPtr       randr_crtc;

+    #else

+	void            *randr_crtc;

+    #endif

+    };

+

+    

+5. Output functions.

+

+6. Configuration

+

+Because the configuration file syntax is fixed,

+this was done by creating new "Driver" section options that hook specific

+outputs to specific "Monitor" sections in the file. The option:

+section of the form:

+

+	Option	"monitor-VGA" "My VGA Monitor"

+

+connects the VGA output of this driver to the "Monitor" section with

+Identifier "My VGA Monitor". All of the usual monitor options can now be

+placed in that "Monitor" section and will be applied to the VGA output

+configuration.

diff --git a/xorg-server/hw/xfree86/doc/Registry b/xorg-server/hw/xfree86/doc/Registry
index 89a5f10fa..48e24a2f4 100644
--- a/xorg-server/hw/xfree86/doc/Registry
+++ b/xorg-server/hw/xfree86/doc/Registry
@@ -1,409 +1,409 @@
-This is the XFree86 driver/module registry.  To avoid name space clashes and

-to maintain some consistency between drivers the important name spaces are

-maintained here.

-

-1. Module Names.

-

-Each module is required to have a unique name.  Registered names are:

-

-GLcore

-acecad

-afb

-apm

-ark

-ati

-atimisc

-bitmap

-bt8xx

-calcomp

-cfb

-cfb16

-cfb24

-cfb32

-chips

-cirrus

-citron

-cyrix

-dbe

-ddc

-digitaledge

-dmc

-dri

-drm

-dynapro

-elo2300

-elographics

-extmod

-fb

-fbdev

-fbdevhw

-fi12x6

-freetype

-glide

-glint

-glx

-hyperpen

-i128

-i2c

-i740

-i810

-imstt

-int10

-joystick

-keyboard

-layer

-magellan

-magictouch

-mfb

-mga

-microtouch

-mouse

-msp34xx

-mutouch

-neomagic

-newport

-nv

-pcidata

-penmount

-pex5

-r128

-radeon

-rac

-ramdac

-record

-rendition

-s3

-s3virge

-savage

-shadow

-shadowfb

-siliconmotion

-sis

-spaceorb

-speedo

-summa

-sunbw2

-suncg14

-suncg3

-suncg6

-sunffb

-sunleo

-suntcx

-tdfx

-tga

-trident

-tseng

-type1

-v4l

-vbe

-vesa

-vga

-vgahw

-vmware

-void

-wacom

-xaa

-xf1bpp

-xf24_32bpp

-xf4bpp

-xf8_16bpp

-xf8_32bpp

-xf8_32wid

-xie

-xtrap

-xtt

-

-2. External Module Object Symbols.

-

-Each module is required to use a unique prefix or prefixes for all of

-its externally visible symbols. They should be unique without regard to

-case.  Registered prefixes are:

-

-ati

-bt8xx

-cfb

-chips

-fi12x6

-glide

-glint

-mfb

-mga

-msp34xx

-neo

-permedia

-tseng

-vga

-vgahw

-vmware

-xaa

-xf1bpp

-xf4bpp

-

-3. Chipset Names.

-

-Each video driver is required to use a unique set of chipset names.  Case,

-white space and underscore characters are ignored when comparing chipset

-names.  All names listed here are in lower case with all white space and

-underscores removed.  Registered chipset names are:

-

-ati

-ativga

-ct64200

-ct64300

-ct65520

-ct65525

-ct65530

-ct65535

-ct65540

-ct65545

-ct65546

-ct65548

-ct65550

-ct65554

-ct65555

-ct68554

-ct69000

-et4000

-et4000w32

-et4000w32i

-et4000w32p

-et6000

-et6100

-generic

-ibmvga

-ibm8514

-mach32

-mach64

-mach8

-mga2064w

-mga1064sg

-mga2164w

-mga2164wagp

-neo2070

-neo2090

-neo2093

-neo2097

-neo2160

-neo2200

-tipm2

-vgawonder

-voodoo

-

-4. Option Names.

-

-Option names and their usage should be consistent between drivers.

-Case, white space and underscore characters are ignored when comparing

-option names.  The prefix "no" may be added or removed from boolean

-option names.  All names listed here are in their preferred user-visible

-form.  Some registered option names are:

-

-Types are:  B = boolean, O = set/unset (no value), I = integer, S = string,

-            A = optional string, F = floating point number Q = frequency

-

-Scopes are: F = global flags, V = video driver, C = common (per screen),

-            I = input drivers, X = XAA, Xv = Xv extension, M = misc.

-

-Names currently in use:

-

-Name                    Type  Scope      Description

-----------------------------------------------------------------------------

-AllowMouseOpenFail        B     F    ignore mouse dev open failure

-AllowNonLocalModInDev     B     F    allow non-local mod of input devs

-AllowNonLocalXvidtune     B     F    allow non-local VidMode connections

-BlankTime                 I     F    Screen saver timeout (min)

-DisableModInDev           B     F    disallow changing input devs

-DisableVidModeExtension   B     F    disable VidMode extension

-DontVTSwitch              B     F    disable Ctrl-Alt-Fn

-DontZap                   B     F    disable Ctrl-Alt-BS sequence

-DontZoom                  B     F    disable Ctrl-Alt-+/-

-NoTrapSignals             B     F    don't trap signals

-OffTime                   I     F    Time before DPMS off mode active (min)

-PciProbe1                 O     F    use PCI probe algorithm 1

-PciProbe2                 O     F    use PCI probe algorithm 2

-PciForceConfig1           O     F    force PCI config type 1

-PciForceConfig2           O     F    force PCI config type 2

-Pixmap                    I     F    depth 24 pixmap size (24 or 32)

-StandbyTime               I     F    Time before DPMS standby active (min)

-SuspendTime               I     F    Time before DPMS suspend mode active (min)

-

-BackingStore              B     C    Enable backing store

-DDC                       B     C    Enable/disable DDC

-DDC1                      B     C    Enable/disable DDC1

-DDC2                      B     C    Enable/disable DDC2

-DPMS                      O     C    Enable DPMS

-MTRR                      B     C    Enable/disable setting MTRRs

-

-BaudRate                  I     I    Serial port baud rate

-ButtonNumber              I     I    Button number (for touch screen?)

-ButtonThreshold           I     I    ??

-ClearDTR                  O     I    Clear serial port DTR

-ClearRTS                  O     I    Clear serial port RTS

-DataBits                  I     I    Serial port data bits

-DemandLoad                O     I    ??

-Device                    S     I    Device file name

-DeviceName                S     I    Input device name

-FlowControl               S     I    Serial flow control ("xon", "none")

-Floating                  B     I    Device initialised as floating

-HistorySize               I     I    ??

-MaxX                      I     I    Maximum X coordinate

-MaxY                      I     I    Maximum Y coordinate

-MinX                      I     I    Minimum X coordinate

-MinY                      I     I    Minimum Y coordinate

-Parity                    S     I    Serial port parity ("odd", "even", "none")

-ReportDelay               I     I    ??

-ReportingMode             S     I    may be "raw" or "scaled"

-ScreenNumber              I     I    Screen number (for touch screen)

-SendCoreEvents            B     I    Send core events

-StopBits                  I     I    Serial port stop bits

-SwapXY                    B     I    Swap the X and Y axes

-UntouchDelay              I     I    ??

-Vmin                      I     I    Tty VMIN

-Vtime                     I     I    Tty VTIME

-

-

-18BitBus                  B     V    ??

-8Plus16                   B     V    Enable depth 8 + depth 16 with overlay

-8Plus24                   B     V    Enable depth 8 + depth 24 with overlay

-BlockWrite                B     V    Enable/disable block write

-ColorKey                  I     V    Set the color key for overlay modes

-CompositeSync             B     V    Composite sync

-CRTDisplay                B     V    Force display on CRT, not LCD

-CRTScreen                 B     V    Display on CRT, not LCD (Obsolete)

-EarlyRasPrecharge         O     V    Early RAS pre-charge

-FastDRAM                  O     V    Fast DRAM

-FifoAggressive            O     V    Aggressive FIFO setting

-FifoConservative          O     V    Conservative FIFO setting

-FifoModerate              O     V    Moderate FIFO setting

-FireGL3000                B     V    Card is Diamond FireGL3000

-FixPanelSize              B     V    ??

-FPClock8                  Q     V    Flat panel clock for 8bpp fb (MHz)

-FPClock16                 Q     V    Flat panel clock for 16bpp fb (MHz)

-FPClock24                 Q     V    Flat panel clock for 24bpp fb (MHz)

-FPClock32                 Q     V    Flat panel clock for 32bpp fb (MHz)

-FPMVRAM                   O     V    Fast page mode VRAM

-FramebufferWC             B     V    Enable/disable WC for the framebuffer

-GlideDevice               I     V    Selects which Voodoo board to use

-HiBitHigh                 O     V    High clock bit default to set

-HiBitLow                  O     V    High clock bit default to cleared

-HWClocks                  B     V    Enable/disable HW clocks

-HWCursor                  B     V    Enable/disable HW cursor

-LateRasPrecharge          O     V    Late RAS pre-charge

-Legend                    O     V    Card is Legend ET4000

-LCDCenter                 B     V    Enable/disable centering for LCD displays

-Linear                    B     V    Enable/disable linear framebuffer

-MCLK                      Q     V    Specify the current MCLK value (MHz)

-MedDRAM                   B     V    Medium speed DRAM

-MemCfg1                   I     V    ??

-MemCfg2                   I     V    ??

-MGASDRAM                  B     V    Mga card has SDRAM

-MMIO                      B     V    Enable/disable memory mapped I/O

-MMIOCache                 B     V    Enable/Disable MMIO cache

-MuxThreshold              I     V    Multiplexing threshold (kHz)

-NoAccel                   B     V    Disable/enable acceleration

-NoClockChip               B     V    ??

-NoStretch                 B     V    Disable/enable stretching for LCD displays

-OnAtExit                  B     V    Leave video signal on when exiting server

-OverclockMem              B     V    Enable memory overclocking

-Overlay                   A     V    Enable multi-depth/overlay.  An optional

-                                     string "M,N" may be specified, where

-                                     M, N are the depths.

-PanelDisplay              B     V    Force display on LCD

-PciBurst                  B     V    Enable/disable PCI burst mode

-PciRetry                  B     V    Enable/disable PCI retries

-ProbeClocks               B     V    Force probe for non-programmable clocks

-ReferenceClock            Q     V    Clock generator reference frequency

-RGBbits                   I     V    Number of significant bits per rgb

-Rotate                    S     V    Rotate the virtual display (CW or CCW)

-SetLCDClk                 Q     V    Set LCD clock (MHz)

-SetMclk                   Q     V    Set Memory Clock (MHz)

-ShadowFB                  B     V    Enable shadow framebuffer layer

-ShowCache                 B     V    Enable viewing of offscreen memory

-ShowOverscan              O     V    Set the overscan area to a visible colour

-SlowDRAM                  O     V    Slow DRAM

-SlowEDODRAM               O     V    Slow EDO DRAM

-STN                       B     V    STN screen type (??)

-SWCursor                  B     V    Enable/disable SW cursor

-SuspendHack               B     V    ??

-SyncOnGreen               B     V    Enable/disable sync on green

-TurboQueue                B     V    Enable/disable turbo queue

-UseFBDev                  B     V    Use the fbdev driver interface

-UseModeLine               B     V    Use Modeline (??)

-W32Interleave             B     V    ??

-

-Buffers			  I	Xv   Number of buffers

-Device			  S	Xv   Device file name

-Expose                    B     Xv   Disable occlusion clipping (see DESIGN)

-FramesPerSec		  I	Xv   Max. refresh frequency

-

-XAA options.  All are of type "O" and scope "X", and are self-explanatory

-

-XaaNoColor8x8PatternFillRect

-XaaNoColor8x8PatternFillTrap

-XaaNoCPUToScreenColorExpandFill

-XaaNoDashedBresenhamLine

-XaaNoDashedTwoPointLine

-XaaNoScreenToScreenCopy

-XaaNoImageReadRect

-XaaNoImageWriteRect

-XaaNoMono8x8PatternFillRect

-XaaNoMono8x8PatternFillTrap

-XaaNoOffscreenPixmaps

-XaaNoPixmapCache

-XaaNoScanlineCPUToScreenColorExpandFill

-XaaNoScanlineImageWriteRect

-XaaNoScreenToScreenColorExpandFill

-XaaNoSolidBresenhamLine

-XaaNoSolidFillRect

-XaaNoSolidFillTrap

-XaaNoSolidHorVertLine

-XaaNoSolidTwoPointLine

-

-

-Names used in previous versions:

-

-16Clocks

-8Clocks

-ClkDiv2

-EDO VRAM

-ExternDisp

-ExtFramBuf

-FastVRAM

-FavorBitBlt

-InternDisp

-NoBitBlt

-NoFontCache

-NoImageBlt

-NoMemAccess

-NoPciDisconnect

-NoPixmapCache

-NoProgramClocks

-NoSplitXfer

-OverrideBIOS

-OverrideValidateMode

-ProgLcdModeRegs

-ProgLcdModeStretch

-SlowDRAMrefresh

-SlowVRAM

-SwapHiBit

-

-

-5. Ramdac Names.

-

-Ramdac names should be consistent between drivers.  Case, white space

-and underscore characters are ignored when comparing ramdac names.  All

-names listed here are in lower case with all white space and underscores

-removed.

-

-

-6. Clock Chip Names.

-

-Clock chip names should be consistent between drivers.  Case, white

-space and underscore characters are ignored when comparing clock chip

-names.  All names listed here are in lower case with all white space

-and underscores removed.

-

-

-

-

-

-$XFree86: xc/programs/Xserver/hw/xfree86/Registry,v 1.18 2002/04/06 18:31:09 tsi Exp $

+This is the XFree86 driver/module registry.  To avoid name space clashes and
+to maintain some consistency between drivers the important name spaces are
+maintained here.
+
+1. Module Names.
+
+Each module is required to have a unique name.  Registered names are:
+
+GLcore
+acecad
+afb
+apm
+ark
+ati
+atimisc
+bitmap
+bt8xx
+calcomp
+cfb
+cfb16
+cfb24
+cfb32
+chips
+cirrus
+citron
+cyrix
+dbe
+ddc
+digitaledge
+dmc
+dri
+drm
+dynapro
+elo2300
+elographics
+extmod
+fb
+fbdev
+fbdevhw
+fi12x6
+freetype
+glide
+glint
+glx
+hyperpen
+i128
+i2c
+i740
+i810
+imstt
+int10
+joystick
+keyboard
+layer
+magellan
+magictouch
+mfb
+mga
+microtouch
+mouse
+msp34xx
+mutouch
+neomagic
+newport
+nv
+pcidata
+penmount
+pex5
+r128
+radeon
+rac
+ramdac
+record
+rendition
+s3
+s3virge
+savage
+shadow
+shadowfb
+siliconmotion
+sis
+spaceorb
+speedo
+summa
+sunbw2
+suncg14
+suncg3
+suncg6
+sunffb
+sunleo
+suntcx
+tdfx
+tga
+trident
+tseng
+type1
+v4l
+vbe
+vesa
+vga
+vgahw
+vmware
+void
+wacom
+xaa
+xf1bpp
+xf24_32bpp
+xf4bpp
+xf8_16bpp
+xf8_32bpp
+xf8_32wid
+xie
+xtrap
+xtt
+
+2. External Module Object Symbols.
+
+Each module is required to use a unique prefix or prefixes for all of
+its externally visible symbols. They should be unique without regard to
+case.  Registered prefixes are:
+
+ati
+bt8xx
+cfb
+chips
+fi12x6
+glide
+glint
+mfb
+mga
+msp34xx
+neo
+permedia
+tseng
+vga
+vgahw
+vmware
+xaa
+xf1bpp
+xf4bpp
+
+3. Chipset Names.
+
+Each video driver is required to use a unique set of chipset names.  Case,
+white space and underscore characters are ignored when comparing chipset
+names.  All names listed here are in lower case with all white space and
+underscores removed.  Registered chipset names are:
+
+ati
+ativga
+ct64200
+ct64300
+ct65520
+ct65525
+ct65530
+ct65535
+ct65540
+ct65545
+ct65546
+ct65548
+ct65550
+ct65554
+ct65555
+ct68554
+ct69000
+et4000
+et4000w32
+et4000w32i
+et4000w32p
+et6000
+et6100
+generic
+ibmvga
+ibm8514
+mach32
+mach64
+mach8
+mga2064w
+mga1064sg
+mga2164w
+mga2164wagp
+neo2070
+neo2090
+neo2093
+neo2097
+neo2160
+neo2200
+tipm2
+vgawonder
+voodoo
+
+4. Option Names.
+
+Option names and their usage should be consistent between drivers.
+Case, white space and underscore characters are ignored when comparing
+option names.  The prefix "no" may be added or removed from boolean
+option names.  All names listed here are in their preferred user-visible
+form.  Some registered option names are:
+
+Types are:  B = boolean, O = set/unset (no value), I = integer, S = string,
+            A = optional string, F = floating point number Q = frequency
+
+Scopes are: F = global flags, V = video driver, C = common (per screen),
+            I = input drivers, X = XAA, Xv = Xv extension, M = misc.
+
+Names currently in use:
+
+Name                    Type  Scope      Description
+----------------------------------------------------------------------------
+AllowMouseOpenFail        B     F    ignore mouse dev open failure
+AllowNonLocalModInDev     B     F    allow non-local mod of input devs
+AllowNonLocalXvidtune     B     F    allow non-local VidMode connections
+BlankTime                 I     F    Screen saver timeout (min)
+DisableModInDev           B     F    disallow changing input devs
+DisableVidModeExtension   B     F    disable VidMode extension
+DontVTSwitch              B     F    disable Ctrl-Alt-Fn
+DontZap                   B     F    disable Ctrl-Alt-BS sequence
+DontZoom                  B     F    disable Ctrl-Alt-+/-
+NoTrapSignals             B     F    don't trap signals
+OffTime                   I     F    Time before DPMS off mode active (min)
+PciProbe1                 O     F    use PCI probe algorithm 1
+PciProbe2                 O     F    use PCI probe algorithm 2
+PciForceConfig1           O     F    force PCI config type 1
+PciForceConfig2           O     F    force PCI config type 2
+Pixmap                    I     F    depth 24 pixmap size (24 or 32)
+StandbyTime               I     F    Time before DPMS standby active (min)
+SuspendTime               I     F    Time before DPMS suspend mode active (min)
+
+BackingStore              B     C    Enable backing store
+DDC                       B     C    Enable/disable DDC
+DDC1                      B     C    Enable/disable DDC1
+DDC2                      B     C    Enable/disable DDC2
+DPMS                      O     C    Enable DPMS
+MTRR                      B     C    Enable/disable setting MTRRs
+
+BaudRate                  I     I    Serial port baud rate
+ButtonNumber              I     I    Button number (for touch screen?)
+ButtonThreshold           I     I    ??
+ClearDTR                  O     I    Clear serial port DTR
+ClearRTS                  O     I    Clear serial port RTS
+DataBits                  I     I    Serial port data bits
+DemandLoad                O     I    ??
+Device                    S     I    Device file name
+DeviceName                S     I    Input device name
+FlowControl               S     I    Serial flow control ("xon", "none")
+Floating                  B     I    Device initialised as floating
+HistorySize               I     I    ??
+MaxX                      I     I    Maximum X coordinate
+MaxY                      I     I    Maximum Y coordinate
+MinX                      I     I    Minimum X coordinate
+MinY                      I     I    Minimum Y coordinate
+Parity                    S     I    Serial port parity ("odd", "even", "none")
+ReportDelay               I     I    ??
+ReportingMode             S     I    may be "raw" or "scaled"
+ScreenNumber              I     I    Screen number (for touch screen)
+SendCoreEvents            B     I    Send core events
+StopBits                  I     I    Serial port stop bits
+SwapXY                    B     I    Swap the X and Y axes
+UntouchDelay              I     I    ??
+Vmin                      I     I    Tty VMIN
+Vtime                     I     I    Tty VTIME
+
+
+18BitBus                  B     V    ??
+8Plus16                   B     V    Enable depth 8 + depth 16 with overlay
+8Plus24                   B     V    Enable depth 8 + depth 24 with overlay
+BlockWrite                B     V    Enable/disable block write
+ColorKey                  I     V    Set the color key for overlay modes
+CompositeSync             B     V    Composite sync
+CRTDisplay                B     V    Force display on CRT, not LCD
+CRTScreen                 B     V    Display on CRT, not LCD (Obsolete)
+EarlyRasPrecharge         O     V    Early RAS pre-charge
+FastDRAM                  O     V    Fast DRAM
+FifoAggressive            O     V    Aggressive FIFO setting
+FifoConservative          O     V    Conservative FIFO setting
+FifoModerate              O     V    Moderate FIFO setting
+FireGL3000                B     V    Card is Diamond FireGL3000
+FixPanelSize              B     V    ??
+FPClock8                  Q     V    Flat panel clock for 8bpp fb (MHz)
+FPClock16                 Q     V    Flat panel clock for 16bpp fb (MHz)
+FPClock24                 Q     V    Flat panel clock for 24bpp fb (MHz)
+FPClock32                 Q     V    Flat panel clock for 32bpp fb (MHz)
+FPMVRAM                   O     V    Fast page mode VRAM
+FramebufferWC             B     V    Enable/disable WC for the framebuffer
+GlideDevice               I     V    Selects which Voodoo board to use
+HiBitHigh                 O     V    High clock bit default to set
+HiBitLow                  O     V    High clock bit default to cleared
+HWClocks                  B     V    Enable/disable HW clocks
+HWCursor                  B     V    Enable/disable HW cursor
+LateRasPrecharge          O     V    Late RAS pre-charge
+Legend                    O     V    Card is Legend ET4000
+LCDCenter                 B     V    Enable/disable centering for LCD displays
+Linear                    B     V    Enable/disable linear framebuffer
+MCLK                      Q     V    Specify the current MCLK value (MHz)
+MedDRAM                   B     V    Medium speed DRAM
+MemCfg1                   I     V    ??
+MemCfg2                   I     V    ??
+MGASDRAM                  B     V    Mga card has SDRAM
+MMIO                      B     V    Enable/disable memory mapped I/O
+MMIOCache                 B     V    Enable/Disable MMIO cache
+MuxThreshold              I     V    Multiplexing threshold (kHz)
+NoAccel                   B     V    Disable/enable acceleration
+NoClockChip               B     V    ??
+NoStretch                 B     V    Disable/enable stretching for LCD displays
+OnAtExit                  B     V    Leave video signal on when exiting server
+OverclockMem              B     V    Enable memory overclocking
+Overlay                   A     V    Enable multi-depth/overlay.  An optional
+                                     string "M,N" may be specified, where
+                                     M, N are the depths.
+PanelDisplay              B     V    Force display on LCD
+PciBurst                  B     V    Enable/disable PCI burst mode
+PciRetry                  B     V    Enable/disable PCI retries
+ProbeClocks               B     V    Force probe for non-programmable clocks
+ReferenceClock            Q     V    Clock generator reference frequency
+RGBbits                   I     V    Number of significant bits per rgb
+Rotate                    S     V    Rotate the virtual display (CW or CCW)
+SetLCDClk                 Q     V    Set LCD clock (MHz)
+SetMclk                   Q     V    Set Memory Clock (MHz)
+ShadowFB                  B     V    Enable shadow framebuffer layer
+ShowCache                 B     V    Enable viewing of offscreen memory
+ShowOverscan              O     V    Set the overscan area to a visible colour
+SlowDRAM                  O     V    Slow DRAM
+SlowEDODRAM               O     V    Slow EDO DRAM
+STN                       B     V    STN screen type (??)
+SWCursor                  B     V    Enable/disable SW cursor
+SuspendHack               B     V    ??
+SyncOnGreen               B     V    Enable/disable sync on green
+TurboQueue                B     V    Enable/disable turbo queue
+UseFBDev                  B     V    Use the fbdev driver interface
+UseModeLine               B     V    Use Modeline (??)
+W32Interleave             B     V    ??
+
+Buffers			  I	Xv   Number of buffers
+Device			  S	Xv   Device file name
+Expose                    B     Xv   Disable occlusion clipping (see DESIGN)
+FramesPerSec		  I	Xv   Max. refresh frequency
+
+XAA options.  All are of type "O" and scope "X", and are self-explanatory
+
+XaaNoColor8x8PatternFillRect
+XaaNoColor8x8PatternFillTrap
+XaaNoCPUToScreenColorExpandFill
+XaaNoDashedBresenhamLine
+XaaNoDashedTwoPointLine
+XaaNoScreenToScreenCopy
+XaaNoImageReadRect
+XaaNoImageWriteRect
+XaaNoMono8x8PatternFillRect
+XaaNoMono8x8PatternFillTrap
+XaaNoOffscreenPixmaps
+XaaNoPixmapCache
+XaaNoScanlineCPUToScreenColorExpandFill
+XaaNoScanlineImageWriteRect
+XaaNoScreenToScreenColorExpandFill
+XaaNoSolidBresenhamLine
+XaaNoSolidFillRect
+XaaNoSolidFillTrap
+XaaNoSolidHorVertLine
+XaaNoSolidTwoPointLine
+
+
+Names used in previous versions:
+
+16Clocks
+8Clocks
+ClkDiv2
+EDO VRAM
+ExternDisp
+ExtFramBuf
+FastVRAM
+FavorBitBlt
+InternDisp
+NoBitBlt
+NoFontCache
+NoImageBlt
+NoMemAccess
+NoPciDisconnect
+NoPixmapCache
+NoProgramClocks
+NoSplitXfer
+OverrideBIOS
+OverrideValidateMode
+ProgLcdModeRegs
+ProgLcdModeStretch
+SlowDRAMrefresh
+SlowVRAM
+SwapHiBit
+
+
+5. Ramdac Names.
+
+Ramdac names should be consistent between drivers.  Case, white space
+and underscore characters are ignored when comparing ramdac names.  All
+names listed here are in lower case with all white space and underscores
+removed.
+
+
+6. Clock Chip Names.
+
+Clock chip names should be consistent between drivers.  Case, white
+space and underscore characters are ignored when comparing clock chip
+names.  All names listed here are in lower case with all white space
+and underscores removed.
+
+
+
+
+
+$XFree86: xc/programs/Xserver/hw/xfree86/Registry,v 1.18 2002/04/06 18:31:09 tsi Exp $
diff --git a/xorg-server/hw/xfree86/doc/ddxDesign.xml b/xorg-server/hw/xfree86/doc/ddxDesign.xml
index a6b9da2d5..24b0c0324 100644
--- a/xorg-server/hw/xfree86/doc/ddxDesign.xml
+++ b/xorg-server/hw/xfree86/doc/ddxDesign.xml
@@ -1306,7 +1306,7 @@ Here is what <function>InitOutput()</function> does:
 
       <blockquote><para>
 	  <programlisting>
-    Bool ChipScreenInit(int index, ScreenPtr pScreen,
+    Bool ChipScreenInit(ScreenPtr pScreen,
                         int argc, char **argv);
 	  </programlisting>
 	  <blockquote><para>
@@ -1442,7 +1442,7 @@ Here is what <function>InitOutput()</function> does:
 
       <blockquote><para>
 	  <programlisting>
-    Bool ChipSwitchMode(int index, DisplayModePtr mode, int flags);
+    Bool ChipSwitchMode(int index, DisplayModePtr mode);
 	  </programlisting>
 	  <blockquote><para>
       Initialises the new mode for the screen identified by
@@ -1464,7 +1464,7 @@ Here is what <function>InitOutput()</function> does:
 
       <blockquote><para>
 	  <programlisting>
-    void ChipAdjustFrame(int index, int x, int y, int flags);
+    void ChipAdjustFrame(int index, int x, int y);
 	  </programlisting>
 	  <blockquote><para>
       Changes the viewport for the screen identified by
@@ -1572,7 +1572,7 @@ Here is what <function>InitOutput()</function> does:
 
       <blockquote><para>
 	  <programlisting>
-    Bool ChipEnterVT(int index, int flags);
+    Bool ChipEnterVT(ScrnInfoPtr pScrn);
 	  </programlisting>
 	  <blockquote><para>
       This function should initialise the current video mode and
@@ -1589,7 +1589,7 @@ Here is what <function>InitOutput()</function> does:
 
       <blockquote><para>
 	  <programlisting>
-    void ChipLeaveVT(int index, int flags);
+    void ChipLeaveVT(ScrnInfoPtr pScrn);
 	  </programlisting>
 	  <blockquote><para>
       This function should restore the saved video state.  If
@@ -1691,7 +1691,7 @@ but their presence is optional.
 
       <blockquote><para>
 	  <programlisting>
-    ModeStatus ChipValidMode(int index, DisplayModePtr mode,
+    ModeStatus ChipValidMode(ScrnInfoPtr pScrn, DisplayModePtr mode,
                              Bool verbose, int flags);
 	  </programlisting>
 	  <blockquote><para>
@@ -1739,7 +1739,7 @@ MODECHECK_FINAL are intended for checks that may involve more than one mode.
 
       <blockquote><para>
 	  <programlisting>
-    void ChipFreeScreen(int scrnindex, int flags);
+    void ChipFreeScreen(ScrnInfoPtr pScrn);
 	  </programlisting>
 	  <blockquote><para>
       Free any driver-allocated data that may have been allocated up to
@@ -2824,12 +2824,12 @@ Several functions are provided to simplify resource registration:
 
 	  <blockquote><para>
 	      <programlisting>
-    Bool xf86IsScreenPrimary(int scrnIndex);
+    Bool xf86IsScreenPrimary(ScrnInfoPtr pScrn);
 	      </programlisting>
 	      <blockquote><para>
       This function returns <constant>TRUE</constant> if the primary entity
       is registered with the screen referenced by
-      <parameter>scrnIndex</parameter>.
+      <parameter>pScrn</parameter>.
 		</para>
 
 	      </blockquote></para></blockquote>
@@ -9033,7 +9033,7 @@ ZZZModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
 
 	<programlisting>
 static Bool
-ZZZScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ZZZScreenInit(ScreenPtr pScreen, int argc, char **argv)
 {
     /* Get the ScrnInfoRec */
     pScrn = xf86ScreenToScrn(pScreen);
@@ -9051,7 +9051,7 @@ ZZZScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
 
     /* Set the viewport if supported */
 
-    ZZZAdjustFrame(scrnIndex, pScrn-&gt;frameX0, pScrn-&gt;frameY0, 0);
+    ZZZAdjustFrame(pScrn, pScrn-&gt;frameX0, pScrn-&gt;frameY0);
 
     /*
      * Setup the screen's visuals, and initialise the framebuffer
@@ -9220,9 +9220,9 @@ ZZZScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
 
 	<programlisting>
 static Bool
-ZZZSwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
+ZZZSwitchMode(ScrnInfoPtr pScrn, DisplayModePtr mode)
 {
-    return ZZZModeInit(xf86Screens[scrnIndex], mode);
+    return ZZZModeInit(pScrn, mode);
 }
 	</programlisting>
       </sect3>
@@ -9237,7 +9237,7 @@ ZZZSwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
 
 	<programlisting>
 static void
-ZZZAdjustFrame(int scrnIndex, int x, int y, int flags)
+ZZZAdjustFrame(ScrnInfoPtr pScrn, int x, int y)
 {
     /* Adjust the viewport */
 }
@@ -9258,16 +9258,14 @@ ZZZAdjustFrame(int scrnIndex, int x, int y, int flags)
 
 	<programlisting>
 static Bool
-ZZZEnterVT(int scrnIndex, int flags)
+ZZZEnterVT(ScrnInfoPtr pScrn)
 {
-    ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
     return ZZZModeInit(pScrn, pScrn-&gt;currentMode);
 }
 
 static void
-ZZZLeaveVT(int scrnIndex, int flags)
+ZZZLeaveVT(ScrnInfoPtr pScrn)
 {
-    ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
     ZZZRestore(pScrn);
 }
 	</programlisting>
@@ -9288,16 +9286,16 @@ ZZZLeaveVT(int scrnIndex, int flags)
 
 	<programlisting>
 static Bool
-ZZZCloseScreen(int scrnIndex, ScreenPtr pScreen)
+ZZZCloseScreen(ScreenPtr pScreen)
 {
-    ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
+    ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
     if (pScrn-&gt;vtSema) {
         ZZZRestore(pScrn);
         ZZZUnmapMem(pScrn);
     }
     pScrn-&gt;vtSema = FALSE;
     pScreen-&gt;CloseScreen = ZZZPTR(pScrn)-&gt;CloseScreen;
-    return (*pScreen-&gt;CloseScreen)(scrnIndex, pScreen);
+    return (*pScreen-&gt;CloseScreen)(pScreen);
 }
 	</programlisting>
       </sect3>
@@ -9342,13 +9340,13 @@ ZZZSaveScreen(ScreenPtr pScreen, int mode)
 
 	<programlisting>
 static void
-ZZZFreeScreen(int scrnIndex, int flags)
+ZZZFreeScreen(ScrnInfoPtr pScrn)
 {
     /*
      * If the vgahw module is used vgaHWFreeHWRec() would be called
      * here.
      */
-    ZZZFreeRec(xf86Screens[scrnIndex]);
+    ZZZFreeRec(pScrn);
 }
 
 	</programlisting>