aboutsummaryrefslogtreecommitdiff
path: root/xorg-server/hw/xfree86/doc
diff options
context:
space:
mode:
Diffstat (limited to 'xorg-server/hw/xfree86/doc')
-rw-r--r--xorg-server/hw/xfree86/doc/.gitignore4
-rw-r--r--xorg-server/hw/xfree86/doc/README.DRIcomp1108
-rw-r--r--xorg-server/hw/xfree86/doc/README.modes948
-rw-r--r--xorg-server/hw/xfree86/doc/Registry818
-rw-r--r--xorg-server/hw/xfree86/doc/ddxDesign.xml44
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>