Checked in the following released items:

xkeyboard-config-1.4.tar.gz
ttf-bitstream-vera-1.10.tar.gz
font-alias-1.0.1.tar.gz
font-sun-misc-1.0.0.tar.gz
font-sun-misc-1.0.0.tar.gz
font-sony-misc-1.0.0.tar.gz
font-schumacher-misc-1.0.0.tar.gz
font-mutt-misc-1.0.0.tar.gz
font-misc-misc-1.0.0.tar.gz
font-misc-meltho-1.0.0.tar.gz
font-micro-misc-1.0.0.tar.gz
font-jis-misc-1.0.0.tar.gz
font-isas-misc-1.0.0.tar.gz
font-dec-misc-1.0.0.tar.gz
font-daewoo-misc-1.0.0.tar.gz
font-cursor-misc-1.0.0.tar.gz
font-arabic-misc-1.0.0.tar.gz
font-winitzki-cyrillic-1.0.0.tar.gz
font-misc-cyrillic-1.0.0.tar.gz
font-cronyx-cyrillic-1.0.0.tar.gz
font-screen-cyrillic-1.0.1.tar.gz
font-xfree86-type1-1.0.1.tar.gz
font-adobe-utopia-type1-1.0.1.tar.gz
font-ibm-type1-1.0.0.tar.gz
font-bitstream-type1-1.0.0.tar.gz
font-bitstream-speedo-1.0.0.tar.gz
font-bh-ttf-1.0.0.tar.gz
font-bh-type1-1.0.0.tar.gz
font-bitstream-100dpi-1.0.0.tar.gz
font-bh-lucidatypewriter-100dpi-1.0.0.tar.gz
font-bh-100dpi-1.0.0.tar.gz
font-adobe-utopia-100dpi-1.0.1.tar.gz
font-adobe-100dpi-1.0.0.tar.gz
font-util-1.0.1.tar.gz
font-bitstream-75dpi-1.0.0.tar.gz
font-bh-lucidatypewriter-75dpi-1.0.0.tar.gz
font-adobe-utopia-75dpi-1.0.1.tar.gz
font-bh-75dpi-1.0.0.tar.gz
bdftopcf-1.0.1.tar.gz
font-adobe-75dpi-1.0.0.tar.gz
mkfontscale-1.0.6.tar.gz
openssl-0.9.8k.tar.gz
bigreqsproto-1.0.2.tar.gz
xtrans-1.2.2.tar.gz
resourceproto-1.0.2.tar.gz
inputproto-1.4.4.tar.gz
compositeproto-0.4.tar.gz
damageproto-1.1.0.tar.gz
zlib-1.2.3.tar.gz
xkbcomp-1.0.5.tar.gz
freetype-2.3.9.tar.gz
pthreads-w32-2-8-0-release.tar.gz
pixman-0.12.0.tar.gz
kbproto-1.0.3.tar.gz
evieext-1.0.2.tar.gz
fixesproto-4.0.tar.gz
recordproto-1.13.2.tar.gz
randrproto-1.2.2.tar.gz
scrnsaverproto-1.1.0.tar.gz
renderproto-0.9.3.tar.gz
xcmiscproto-1.1.2.tar.gz
fontsproto-2.0.2.tar.gz
xextproto-7.0.3.tar.gz
xproto-7.0.14.tar.gz
libXdmcp-1.0.2.tar.gz
libxkbfile-1.0.5.tar.gz
libfontenc-1.0.4.tar.gz
libXfont-1.3.4.tar.gz
libX11-1.1.5.tar.gz
libXau-1.0.4.tar.gz
libxcb-1.1.tar.gz
xorg-server-1.5.3.tar.gz

8 files changed, 2658 insertions, 0 deletions

diff --git a/xorg-server/hw/xfree86/doc/devel/DebuggingHints b/xorg-server/hw/xfree86/doc/devel/DebuggingHints
new file mode 100644
index 000000000..300fe4813
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/DebuggingHints
@@ -0,0 +1,192 @@
+
+                        Xserver Debugging
+                        =================
+
+This file is  intended to collect helpful hints  on Xserver debugging.
+I merely outline my experiences  here. Somebody else might have better
+methods on  doing it. This person  is therefore invited  to share this
+experience with the rest of the world by adding it here.
+
+Paul Flinders has made some patches to gdb to add support for loadable
+modules.  This version  of gdb  is currently  available as  binary for
+Linux/x86 on Paul's web site:
+
+         www.dawa.demon.co.uk/xfree-gdb
+
+This web-site also contains the patches to gdb 4.18 so you may port it
+to other platforms.
+
+It  loads  the module  symbols  and  supports  all gdb  features  like
+breakpointing, disassembling  and single  stepping. It also  shows the
+exact location of a signal 11. Paul  has fixed the code so that all of
+this is  working even  if using modules  compiled without -g.  You can
+find his latest version on his web site.
+
+If no module aware gdb is available the following hints might help:
+
+1. Use remote  login. This  can be done  thru a network  connection or
+   simply by  connecting a serial  console. This enables you  to watch
+   the  Xservers output while  running set  breakpoints with  gdb etc.
+   Don't even try  to run the Xserver from  a system console. Whenever
+   something  happens gdb  waits for  input. However  the  Xserver has
+   locked the system console  including the keyboard, therefore you'll
+   never  be able  to send  any  input to  gdb. Even  if your  process
+   doesn't crash or you haven't set any breakpoints a vt switch can be
+   hazardous: When doing vt switching a signal is sent; unless you did
+         
+   gdb> handle SIGUSR1 nostop
+
+   gdb waits  for you to continue  the program which  cannot happen as
+   you don't have access to gdb's console.
+
+2. You can  compile any source  file with debugging symbols  to obtain
+   more information  about where an  error occurred. Simply go  to the
+   directory which holds the corresponding object file and do:
+            
+   # rm <file>.o
+   # xc/config/util/makeg.sh <file>.o
+
+   After  relinking the server  or module  gdb is  able to  obtain the
+   necessary debugging information and will show the exact line in the
+   source  where the error ccurred. See also:
+   xc/config/util/makeg.man.
+
+3. In some cases it might be  useful to have the assembler output of a
+   compiled source file. This can be obtained by doing:
+    
+   # make <file>.s
+   
+   or 
+ 
+   # xc/config/util/makeg.sh <file>.s
+
+   Make will use exactly the same rules it uses for building *.o files.
+
+4. In some cases it might be useful to set breakpoints in modules.  If
+   no module  aware gdb is available you  should add a call  to one of
+   the three dummy breakpoint functions
+
+   xf86Break1(), xf86Break2() and xf86Break3()
+
+   to the source  file and recompile the module. You  now just have to
+   set  a  breakpoint  onto  the appropriate  dummy  functions.  These
+   functions are located in the  core part of the server and therefore
+   will be available any time.
+
+5. Without module support gdb is  not able to print the function where
+   an error occurred in a module.
+
+     If you get a line like:
+
+   (gdb) bt
+   #0  0x823b4f5 in ?? ()
+   ....
+
+   You may obtain the function the address belongs to by calling 
+   LoaderPrintSymbol():
+
+   (gdb) call LoaderPrintSymbol(0x823b4f5)
+
+   The symbol  returned might not always  be the name  of the function
+   which contains the address. In  case of static functions the symbol
+   is not known to  the loader. However LoaderPrintSymbol() will print
+   the nearest known  function and the offset from  its start. You may
+   easily find the exact location of the address if you do:
+
+   # objdump --disassemble <file>.o
+
+   <file>.o is the name of the object file containing the symbol printed.
+
+6. Locating static  symbols in modules is  simpler if the  module is a
+   single object  file instead  of a library.  Such a object  file can
+   easily  be build  from  a  library: #  mkdir  tmp #  cd  tmp; ar  x
+   module-path/<libname>.a # ld -r *.o -o module-path/<name>.o
+   
+   When calling  LoaderPrintSymbol() the closes public  symbol will be
+   printed together with  the offset from the symbol's  address.  If a
+   static symbol comes before the  first public symbol in a module The
+   following trick may help:
+
+   create a file 1-<name>.c in tmp/
+   containing:
+   void Dummy-<name>() {}
+    
+   Compile it:
+
+   # gcc -c 1-<name>.c
+
+   and do the link step above.
+
+   This way  Dummy-<name>() will be  the first public function  in the
+   module.   All  addresses in  static  function  can  now be  printed
+   relatively to this address if no other public function comes before
+   this static one.
+
+7. In some situations it is  quite helpful to add debugging symbols to
+   the binary.  This can  be done per  object file. Simply  remove the
+   object file and do
+
+   # makeg
+
+   When looking  for a bug  in a module  these debugging infos  can be
+   very helpful:  Calling LoaderPrintSymbol() as  described above will
+   return a  function and an offset  giving the exact  location of the
+   address  with   respect  to   this  function  entry   point.   When
+   disassembling an  object file with debugging symbols:  # objdump -d
+   -l <file>.o one will  receive a disassembled output containing line
+   number  information. Thus  one can  locate the  exact line  of code
+   where the error occurred.
+
+8. To quickly trace the value of a variable declared in a module three
+   dummy variables have been added to the core part:
+
+   CARD32 xf86DummyVar1;
+   CARD32 xf86DummyVar2;
+   CARD32 xf86DummyVar3;
+
+   The variable can  be assigned to one of them. One  can then use gdb
+   to return the value of this variable:
+
+   gdb> p /x xf86DummyVar1
+
+9. Sometimes it might be useful to check how the preprocessor replaced
+   symbols. One can  obtain a preprocessed version of  the source file
+   by doing:
+
+   make <filename>.i
+
+   This will generate a preprocessed source in <filename>.i.
+
+10. xfree() can catch  if one tries to free a  memory range twice. You
+    will get the message:
+
+       Xalloc error: range already freed in Xrealloc() :-(
+
+  To  find  the  location  from  which  xfree()  was  called  one  can
+  breakpoint on XfreeTrap(). The backtrace should show the origin of the
+  call this call. 
+
+11. To access mapped physical  memory the following functions might be
+    useful.  
+
+    These may be used to  access physical memory that was mapped using
+    the flags VIDMEM_FRAMEBUFFER or VIDMEM_MMIO32:
+
+      CARD8  xf86PeekFb8(CARD8  *p);
+      CARD16 xf86PeekFb16(CARD16 *p);
+      CARD32 xf86PeekFb32(CARD32 *p);
+      void xf86PokeFb8(CARD8  *p, CARD8  v);
+      void xf86PokeFb16(CARD16 *p, CARD16 v);
+      void xf86PokeFb32(CARD16 *p, CARD32 v);
+
+    Physical memory which was  mapped by setting VIDMEM_MMIO should be
+    accessed using the following.  Here  the base address to which the
+    memory is mapped and the offset are required separately.
+
+      CARD8  xf86PeekMmio8(pointer Base, unsigned long Offset);
+      CARD16 xf86PeekMmio16(pointer Base, unsigned long Offset);
+      CARD32 xf86PeekMmio32(pointer Base, unsigned long Offset);
+      void xf86PokeMmio8(pointer Base, unsigned long Offset, CARD8  v);
+      void xf86PokeMmio16(pointer Base, unsigned long Offset, CARD16 v);
+      void xf86PokeMmio32(pointer Base, unsigned long Offset, CARD32 v);
+
diff --git a/xorg-server/hw/xfree86/doc/devel/Domain.note b/xorg-server/hw/xfree86/doc/devel/Domain.note
new file mode 100644
index 000000000..ce0812b22
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/Domain.note
@@ -0,0 +1,159 @@
+The purpose of the changes described here is to implement a more general
+framework for multi-head on systems with more than one host-to-PCI bridge.
+The changes also implement a basic port of XFree86 to SPARC Solaris.
+
+These changes are derived from David S. Miller's submission #4653 to the
+patch list.  David Andrew of Sun Microsystems was also kind enough to
+arrange for a hardware loan for development of these changes.
+
+These changes are known to work on several SPARC SunOS and UltraSPARC
+Linux configurations.  Linux kernel work is in progress to port these
+changes to Linux/PowerPC.
+
+Several loose ends still need to be addressed before these changes can be
+considered stable.  The bulk of this note is devoted to enumerating what
+remains to be done, along with other notes, broken down into various broad
+categories.
+
+SPARC SunOS (aka Solaris)
+-------------------------
+- An overview of this XFree86 port is available in README.Solaris.
+- The keyboard map code in hw/xfree86/os-support/sunos/sun_kbdEv.c needs
+  to be extended to handle more than only the sun5 keyboard I targeted it
+  for.  Even for the sun5, the map is incomplete as several keys are not
+  mapped.  What is there is just barely usable.
+- On exit, the server will zero out /dev/fb, but that might not be the
+  right thing to do for all primary adapters.  This does however
+  appear to emulate the behaviour of Sun's commercial servers.  It also
+  eliminates the need for output drivers to save and restore video memory
+  contents.  (They still need to save/restore the mode timing however.)
+  This also chimes into a long-standing XFree86 policy to not save/restore
+  video memory contents if the mode on entry is found to be non-VGA, a
+  policy several existing drivers comply with.
+- The SBUS drivers (sunbw2, suncg14, suncg3, suncg6, sunffb, sunleo and
+  suntcx), the common layer's SBUS code and the fbdev driver have all
+  only been compile tested.  There are likely to be Linux'isms within
+  them that remain to be dealt with.
+- It still needs to be verified whether or not this work adversely
+  affected support for ix86 Solaris.
+
+UltraSPARC Linux
+----------------
+- Although this code can be compiled using any Linux/SPARC64 kernel, it
+  can only run successfully using 2.4.12 or later.
+- I haven't had time to sufficiently dig into XKB to properly configure it
+  for sun5 keyboards.  Given XFree86 on Linux/SPARC has been around for a
+  while, it's likely someone has already done this, and I'd appreciate
+  receiving a copy of a working XF86Config input section.
+
+PowerPC Linux
+-------------
+- As mentioned above, kernel work is in progress to port this PCI scheme
+  to Linux/PowerPC.
+- Aside from kernel work, the inX() and outX() definitions in compiler.h
+  will need to be changed to do something akin to their SPARC definitions,
+  i.e. consider their port argument to be a virtual address.
+
+Other Linux ports to multi-domain architectures
+-----------------------------------------------
+- Comments in os-support/bus/linuxPci.c document the kernel interface
+  required to port these changes.  In short, Linux ports, such as Alpha
+  and mips, should follow SPARC and PowerPC's lead in providing support to
+  mmap() PCI devices through their /proc/bus/pci pseudo-files and to treat
+  such requests for host bridges as requests to mmap() space provided by
+  these bridges.
+
+Other OS's
+----------
+- In the right hands, either linuxPci.c or sparcPci.c can be used as a
+  guide for what would need to be done to port this scheme to other OS's.
+  Perhaps the largest difference between the two (in terms of interface to
+  the common layer) is that the SunOS port includes internally generated
+  domain numbers in PCITAG's, whereas the Linux port doesn't need to.  The
+  remainder of the PCI code (which is OS-independent) can handle either
+  scheme.
+- Required entry points are xf86GetPciDomain(), xf86MapDomainMemory(),
+  xf86MapDomainIO() and xf86ReadDomainMemory().  Replacements for
+  xf86BusAccWindowsFromOS(), xf86PciBusAccWindowsFromOS() and
+  xf86AccResFromOS() might also be required.
+- Development of these changes has detected the fact that the XFree86 port
+  to the PowerMax OS is broken, and has been for some time, i.e. since
+  shortly after its introduction, back in the 3.9* days.
+
+SPARC PCI (OS-independent)
+--------------------------
+- The "Simba" PCI-to-PCI bridge used in SPARC's does not implement VGA
+  routing, as defined in the PCI specs.  Fortunately, OpenPROM seems to
+  always route VGA resources to the bus with PCI connectors, but this also
+  causes the common layer to not mark any PCI adapter as primary.
+
+Multiple PCI domains (architecture- and OS-independent)
+-------------------------------------------------------
+- This implementation assumes every host-to-PCI bridge provides access to
+  a separate PCI domain.  Each such domain provides three different
+  "address" spaces:  PCI configuration, I/O and memory.  The
+  implementation can also deal with situations where more than one PCI
+  domain share (different subsets of) the same PCI configuration space.  I
+  have unconfirmed information that suggests it might be necessary to also
+  allow the sharing of PCI memory spaces.
+- This implementation also assumes the CPU's physical address space
+  includes the entirety of each domain's I/O and memory spaces.  I know
+  this'll need to be changed to deal with the so-called UniNorth bridge,
+  found on PowerPC's, which allows access to only a subset of the memory
+  space behind it.
+- Ideally, the common layer should mark as primary up to one PCI adapter
+  per domain.  This has yet to be done.
+- Something needs to be done about PCI master aborts on primary buses.
+  For details on this, see my long-winded diatribe in sparcPci.c, and
+  related comments in linuxPci.c.  Suffice it to say here that I see the
+  eventual implementation of host bridge drivers within XFree86 as
+  unavoidable at this point.
+- DGA is broken on multi-domain platforms.  The information passed to the
+  client to locate the framebuffer still needs to be revised.  The best way
+  to deal with this is to change all drivers' OpenFramebuffer() function to
+  call a common layer routine to set the device name and displacements to be
+  returned to the DGA client.
+
+Output drivers
+--------------
+Most drivers currently used on ix86 need(ed) source code changes.
+- Calls to xf86ReadBIOS() and xf86MapVidMem() were replaced with calls to
+  xf86ReadDomainMemory() and xf86MapDomainMemory() respectively.  Except
+  for the "ati" and "atimisc" modules, this has already been done.
+- All ix86-style I/O port numbers need to be declared as an IOADDRESS, a
+  type defined in xf86Pci.h as "unsigned long".  Such port numbers also
+  need to be offset by a displacement which is also defined as an
+  IOADDRESS.  Before a driver's PreInit() is called, the common layer
+  makes this displacement available in ScrnInfoRec.domainIOBase.  For
+  single-domain architectures, such as ix86, domainIOBase will always be
+  zero.  Current use of vgaHWRec.PIOOffset has also been adjusted
+  accordingly.  Some drivers have been changed to keep a copy of this
+  displacement in their private structure.  Internally, an IOADDRESS is
+  actually a pointer that has been recasted to an unsigned long, but the
+  common layer "hides" this fact from the driver ABI, which means that I/O
+  port numbers, as seen by drivers, remain as integers rather than
+  addresses.  Aside from the ati and atimisc modules, s3, sis and tseng
+  are the only modules left whose I/O still needs to be converted (I've
+  temporarily run out of steam).
+- Note that these conversions are not necessarily sufficient to produce
+  drivers that will work on any given multi-domain architecture.  A driver
+  that, for example, had endianness problems, still does.  But, at least,
+  these conversions, along with the supporting common layer changes, make
+  PCI drivers more widely amenable to porting.
+- rdinx(), wrinx(), modinx(), testrg(), testinx() and testinx2() are not
+  given enough information to allow for the relocation of their I/O.  They
+  are consequently being deleted.  The apm and ark drivers, the only
+  remaining callers of the first three, have been changed to use local
+  definitions instead.  The last three (test*()) were already unused.
+- As a temporary measure, these changes completely disable ISA-style
+  probing on SPARC's and PowerPC's.  This means that driver calls to
+  xf86MatchIsaInstances(), while still valid, will always return detection
+  failure on SPARC's and PowerPC's.  This will be dealt with when a more
+  general master abort handling scheme is implemented.
+- I need to make a decision about the master abort issues mentionned above
+  before I can convert the "ati" and "atimisc" modules.  Consequently,
+  these modules still need to be compiled with -DAVOID_CPIO on
+  multi-domain architectures, and support for Mach64 variants as
+  non-primary heads is not yet available.
+
+$XFree86$
diff --git a/xorg-server/hw/xfree86/doc/devel/Makefile.am b/xorg-server/hw/xfree86/doc/devel/Makefile.am
new file mode 100644
index 000000000..6ca350c38
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/Makefile.am
@@ -0,0 +1,10 @@
+# Documentation for developers that is distributed with the source but
+# not installed on the system for end-users
+
+EXTRA_DIST = \
+	DebuggingHints \
+	Domain.note \
+	RAC.Notes \
+	Registry \
+	exa-driver.txt \
+	README.DRIcomp
diff --git a/xorg-server/hw/xfree86/doc/devel/Makefile.in b/xorg-server/hw/xfree86/doc/devel/Makefile.in
new file mode 100644
index 000000000..7c169aff3
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/Makefile.in
@@ -0,0 +1,542 @@
+# Makefile.in generated by automake 1.10.1 from Makefile.am.
+# @configure_input@
+
+# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+# 2003, 2004, 2005, 2006, 2007, 2008  Free Software Foundation, Inc.
+# This Makefile.in is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
+# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+# PARTICULAR PURPOSE.
+
+@SET_MAKE@
+
+# Documentation for developers that is distributed with the source but
+# not installed on the system for end-users
+VPATH = @srcdir@
+pkgdatadir = $(datadir)/@PACKAGE@
+pkglibdir = $(libdir)/@PACKAGE@
+pkgincludedir = $(includedir)/@PACKAGE@
+am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
+install_sh_DATA = $(install_sh) -c -m 644
+install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
+INSTALL_HEADER = $(INSTALL_DATA)
+transform = $(program_transform_name)
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+build_triplet = @build@
+host_triplet = @host@
+subdir = hw/xfree86/doc/devel
+DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in
+ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
+am__aclocal_m4_deps = $(top_srcdir)/acinclude.m4 \
+	$(top_srcdir)/configure.ac
+am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
+	$(ACLOCAL_M4)
+mkinstalldirs = $(install_sh) -d
+CONFIG_HEADER = $(top_builddir)/include/do-not-use-config.h \
+	$(top_builddir)/include/xorg-server.h \
+	$(top_builddir)/include/dix-config.h \
+	$(top_builddir)/include/xgl-config.h \
+	$(top_builddir)/include/xorg-config.h \
+	$(top_builddir)/include/xkb-config.h \
+	$(top_builddir)/include/xwin-config.h \
+	$(top_builddir)/include/kdrive-config.h
+CONFIG_CLEAN_FILES =
+SOURCES =
+DIST_SOURCES =
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+ACLOCAL = @ACLOCAL@
+ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
+ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
+ALLOCA = @ALLOCA@
+AMTAR = @AMTAR@
+APPDEFAULTDIR = @APPDEFAULTDIR@
+APPLE_APPLICATIONS_DIR = @APPLE_APPLICATIONS_DIR@
+APP_MAN_DIR = @APP_MAN_DIR@
+APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
+AR = @AR@
+AS = @AS@
+AUTOCONF = @AUTOCONF@
+AUTOHEADER = @AUTOHEADER@
+AUTOMAKE = @AUTOMAKE@
+AWK = @AWK@
+BASE_FONT_PATH = @BASE_FONT_PATH@
+BUILD_DATE = @BUILD_DATE@
+BUILD_TIME = @BUILD_TIME@
+CC = @CC@
+CCAS = @CCAS@
+CCASDEPMODE = @CCASDEPMODE@
+CCASFLAGS = @CCASFLAGS@
+CCDEPMODE = @CCDEPMODE@
+CFLAGS = @CFLAGS@
+COMPILEDDEFAULTFONTPATH = @COMPILEDDEFAULTFONTPATH@
+CPP = @CPP@
+CPPFLAGS = @CPPFLAGS@
+CXX = @CXX@
+CXXCPP = @CXXCPP@
+CXXDEPMODE = @CXXDEPMODE@
+CXXFLAGS = @CXXFLAGS@
+CYGPATH_W = @CYGPATH_W@
+DARWIN_LIBS = @DARWIN_LIBS@
+DBUS_CFLAGS = @DBUS_CFLAGS@
+DBUS_LIBS = @DBUS_LIBS@
+DEFAULT_LIBRARY_PATH = @DEFAULT_LIBRARY_PATH@
+DEFAULT_LOGPREFIX = @DEFAULT_LOGPREFIX@
+DEFAULT_MODULE_PATH = @DEFAULT_MODULE_PATH@
+DEFS = @DEFS@
+DEPDIR = @DEPDIR@
+DGA_CFLAGS = @DGA_CFLAGS@
+DGA_LIBS = @DGA_LIBS@
+DIX_CFLAGS = @DIX_CFLAGS@
+DLLTOOL = @DLLTOOL@
+DMXEXAMPLES_DEP_CFLAGS = @DMXEXAMPLES_DEP_CFLAGS@
+DMXEXAMPLES_DEP_LIBS = @DMXEXAMPLES_DEP_LIBS@
+DMXMODULES_CFLAGS = @DMXMODULES_CFLAGS@
+DMXMODULES_LIBS = @DMXMODULES_LIBS@
+DMXXIEXAMPLES_DEP_CFLAGS = @DMXXIEXAMPLES_DEP_CFLAGS@
+DMXXIEXAMPLES_DEP_LIBS = @DMXXIEXAMPLES_DEP_LIBS@
+DMXXMUEXAMPLES_DEP_CFLAGS = @DMXXMUEXAMPLES_DEP_CFLAGS@
+DMXXMUEXAMPLES_DEP_LIBS = @DMXXMUEXAMPLES_DEP_LIBS@
+DRI2PROTO_CFLAGS = @DRI2PROTO_CFLAGS@
+DRI2PROTO_LIBS = @DRI2PROTO_LIBS@
+DRIPROTO_CFLAGS = @DRIPROTO_CFLAGS@
+DRIPROTO_LIBS = @DRIPROTO_LIBS@
+DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
+DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
+DRI_DRIVER_PATH = @DRI_DRIVER_PATH@
+DSYMUTIL = @DSYMUTIL@
+DTRACE = @DTRACE@
+ECHO = @ECHO@
+ECHO_C = @ECHO_C@
+ECHO_N = @ECHO_N@
+ECHO_T = @ECHO_T@
+EGREP = @EGREP@
+EXEEXT = @EXEEXT@
+F77 = @F77@
+FFLAGS = @FFLAGS@
+FILE_MAN_DIR = @FILE_MAN_DIR@
+FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
+FREETYPE_CFLAGS = @FREETYPE_CFLAGS@
+FREETYPE_LIBS = @FREETYPE_LIBS@
+GLX_ARCH_DEFINES = @GLX_ARCH_DEFINES@
+GLX_DEFINES = @GLX_DEFINES@
+GL_CFLAGS = @GL_CFLAGS@
+GL_LIBS = @GL_LIBS@
+GREP = @GREP@
+HAL_CFLAGS = @HAL_CFLAGS@
+HAL_LIBS = @HAL_LIBS@
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_PROGRAM = @INSTALL_PROGRAM@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
+KDRIVE_CFLAGS = @KDRIVE_CFLAGS@
+KDRIVE_INCS = @KDRIVE_INCS@
+KDRIVE_LIBS = @KDRIVE_LIBS@
+KDRIVE_LOCAL_LIBS = @KDRIVE_LOCAL_LIBS@
+KDRIVE_PURE_INCS = @KDRIVE_PURE_INCS@
+KDRIVE_PURE_LIBS = @KDRIVE_PURE_LIBS@
+LAUNCHD = @LAUNCHD@
+LDFLAGS = @LDFLAGS@
+LD_EXPORT_SYMBOLS_FLAG = @LD_EXPORT_SYMBOLS_FLAG@
+LEX = @LEX@
+LEXLIB = @LEXLIB@
+LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
+LIBDRM_CFLAGS = @LIBDRM_CFLAGS@
+LIBDRM_LIBS = @LIBDRM_LIBS@
+LIBOBJS = @LIBOBJS@
+LIBS = @LIBS@
+LIBTOOL = @LIBTOOL@
+LIB_MAN_DIR = @LIB_MAN_DIR@
+LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
+LINUXDOC = @LINUXDOC@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAINT = @MAINT@
+MAKEINFO = @MAKEINFO@
+MAKE_HTML = @MAKE_HTML@
+MAKE_PDF = @MAKE_PDF@
+MAKE_PS = @MAKE_PS@
+MAKE_TEXT = @MAKE_TEXT@
+MESA_SOURCE = @MESA_SOURCE@
+MISC_MAN_DIR = @MISC_MAN_DIR@
+MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
+MKDIR_P = @MKDIR_P@
+MKFONTDIR = @MKFONTDIR@
+MKFONTSCALE = @MKFONTSCALE@
+NMEDIT = @NMEDIT@
+OBJC = @OBJC@
+OBJCCLD = @OBJCCLD@
+OBJCDEPMODE = @OBJCDEPMODE@
+OBJCFLAGS = @OBJCFLAGS@
+OBJCLINK = @OBJCLINK@
+OBJDUMP = @OBJDUMP@
+OBJEXT = @OBJEXT@
+OPENSSL_CFLAGS = @OPENSSL_CFLAGS@
+OPENSSL_LIBS = @OPENSSL_LIBS@
+PACKAGE = @PACKAGE@
+PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
+PACKAGE_NAME = @PACKAGE_NAME@
+PACKAGE_STRING = @PACKAGE_STRING@
+PACKAGE_TARNAME = @PACKAGE_TARNAME@
+PACKAGE_VERSION = @PACKAGE_VERSION@
+PATH_SEPARATOR = @PATH_SEPARATOR@
+PCIACCESS_CFLAGS = @PCIACCESS_CFLAGS@
+PCIACCESS_LIBS = @PCIACCESS_LIBS@
+PCI_TXT_IDS_PATH = @PCI_TXT_IDS_PATH@
+PERL = @PERL@
+PKG_CONFIG = @PKG_CONFIG@
+PROJECTROOT = @PROJECTROOT@
+PS2PDF = @PS2PDF@
+RANLIB = @RANLIB@
+RAWCPP = @RAWCPP@
+RAWCPPFLAGS = @RAWCPPFLAGS@
+SED = @SED@
+SERVER_MISC_CONFIG_PATH = @SERVER_MISC_CONFIG_PATH@
+SET_MAKE = @SET_MAKE@
+SHELL = @SHELL@
+SOLARIS_ASM_CFLAGS = @SOLARIS_ASM_CFLAGS@
+SOLARIS_INOUT_ARCH = @SOLARIS_INOUT_ARCH@
+STRIP = @STRIP@
+TSLIB_CFLAGS = @TSLIB_CFLAGS@
+TSLIB_LIBS = @TSLIB_LIBS@
+UTILS_SYS_LIBS = @UTILS_SYS_LIBS@
+VENDOR_MAN_VERSION = @VENDOR_MAN_VERSION@
+VENDOR_NAME = @VENDOR_NAME@
+VENDOR_NAME_SHORT = @VENDOR_NAME_SHORT@
+VENDOR_RELEASE = @VENDOR_RELEASE@
+VERSION = @VERSION@
+X11APP_ARCHS = @X11APP_ARCHS@
+X11EXAMPLES_DEP_CFLAGS = @X11EXAMPLES_DEP_CFLAGS@
+X11EXAMPLES_DEP_LIBS = @X11EXAMPLES_DEP_LIBS@
+XDMCP_CFLAGS = @XDMCP_CFLAGS@
+XDMCP_LIBS = @XDMCP_LIBS@
+XDMXCONFIG_DEP_CFLAGS = @XDMXCONFIG_DEP_CFLAGS@
+XDMXCONFIG_DEP_LIBS = @XDMXCONFIG_DEP_LIBS@
+XDMX_CFLAGS = @XDMX_CFLAGS@
+XDMX_LIBS = @XDMX_LIBS@
+XDMX_SYS_LIBS = @XDMX_SYS_LIBS@
+XEGLMODULES_CFLAGS = @XEGLMODULES_CFLAGS@
+XEGL_LIBS = @XEGL_LIBS@
+XEGL_SYS_LIBS = @XEGL_SYS_LIBS@
+XEPHYR_CFLAGS = @XEPHYR_CFLAGS@
+XEPHYR_DRI_LIBS = @XEPHYR_DRI_LIBS@
+XEPHYR_INCS = @XEPHYR_INCS@
+XEPHYR_LIBS = @XEPHYR_LIBS@
+XF86CONFIGFILE = @XF86CONFIGFILE@
+XF86MISC_CFLAGS = @XF86MISC_CFLAGS@
+XF86MISC_LIBS = @XF86MISC_LIBS@
+XF86VIDMODE_CFLAGS = @XF86VIDMODE_CFLAGS@
+XF86VIDMODE_LIBS = @XF86VIDMODE_LIBS@
+XGLMODULES_CFLAGS = @XGLMODULES_CFLAGS@
+XGLMODULES_LIBS = @XGLMODULES_LIBS@
+XGLXMODULES_CFLAGS = @XGLXMODULES_CFLAGS@
+XGLXMODULES_LIBS = @XGLXMODULES_LIBS@
+XGLX_LIBS = @XGLX_LIBS@
+XGLX_SYS_LIBS = @XGLX_SYS_LIBS@
+XGL_LIBS = @XGL_LIBS@
+XGL_MODULE_PATH = @XGL_MODULE_PATH@
+XGL_SYS_LIBS = @XGL_SYS_LIBS@
+XKB_BASE_DIRECTORY = @XKB_BASE_DIRECTORY@
+XKB_BIN_DIRECTORY = @XKB_BIN_DIRECTORY@
+XKB_COMPILED_DIR = @XKB_COMPILED_DIR@
+XKM_OUTPUT_DIR = @XKM_OUTPUT_DIR@
+XLIB_CFLAGS = @XLIB_CFLAGS@
+XLIB_LIBS = @XLIB_LIBS@
+XNESTMODULES_CFLAGS = @XNESTMODULES_CFLAGS@
+XNESTMODULES_LIBS = @XNESTMODULES_LIBS@
+XNEST_LIBS = @XNEST_LIBS@
+XNEST_SYS_LIBS = @XNEST_SYS_LIBS@
+XORGCFG_DEP_CFLAGS = @XORGCFG_DEP_CFLAGS@
+XORGCFG_DEP_LIBS = @XORGCFG_DEP_LIBS@
+XORGCONFIG_DEP_CFLAGS = @XORGCONFIG_DEP_CFLAGS@
+XORGCONFIG_DEP_LIBS = @XORGCONFIG_DEP_LIBS@
+XORG_CFLAGS = @XORG_CFLAGS@
+XORG_INCS = @XORG_INCS@
+XORG_LIBS = @XORG_LIBS@
+XORG_MODULES_CFLAGS = @XORG_MODULES_CFLAGS@
+XORG_MODULES_LIBS = @XORG_MODULES_LIBS@
+XORG_OS = @XORG_OS@
+XORG_OS_SUBDIR = @XORG_OS_SUBDIR@
+XORG_SYS_LIBS = @XORG_SYS_LIBS@
+XPRINTMODULES_CFLAGS = @XPRINTMODULES_CFLAGS@
+XPRINTMODULES_LIBS = @XPRINTMODULES_LIBS@
+XPRINTPROTO_CFLAGS = @XPRINTPROTO_CFLAGS@
+XPRINTPROTO_LIBS = @XPRINTPROTO_LIBS@
+XPRINT_CFLAGS = @XPRINT_CFLAGS@
+XPRINT_LIBS = @XPRINT_LIBS@
+XPRINT_SYS_LIBS = @XPRINT_SYS_LIBS@
+XRESEXAMPLES_DEP_CFLAGS = @XRESEXAMPLES_DEP_CFLAGS@
+XRESEXAMPLES_DEP_LIBS = @XRESEXAMPLES_DEP_LIBS@
+XSDL_INCS = @XSDL_INCS@
+XSDL_LIBS = @XSDL_LIBS@
+XSERVERCFLAGS_CFLAGS = @XSERVERCFLAGS_CFLAGS@
+XSERVERCFLAGS_LIBS = @XSERVERCFLAGS_LIBS@
+XSERVERLIBS_CFLAGS = @XSERVERLIBS_CFLAGS@
+XSERVERLIBS_LIBS = @XSERVERLIBS_LIBS@
+XSERVER_LIBS = @XSERVER_LIBS@
+XSERVER_SYS_LIBS = @XSERVER_SYS_LIBS@
+XTSTEXAMPLES_DEP_CFLAGS = @XTSTEXAMPLES_DEP_CFLAGS@
+XTSTEXAMPLES_DEP_LIBS = @XTSTEXAMPLES_DEP_LIBS@
+XVFB_LIBS = @XVFB_LIBS@
+XVFB_SYS_LIBS = @XVFB_SYS_LIBS@
+XWINMODULES_CFLAGS = @XWINMODULES_CFLAGS@
+XWINMODULES_LIBS = @XWINMODULES_LIBS@
+XWIN_LIBS = @XWIN_LIBS@
+XWIN_SERVER_NAME = @XWIN_SERVER_NAME@
+XWIN_SYS_LIBS = @XWIN_SYS_LIBS@
+YACC = @YACC@
+YFLAGS = @YFLAGS@
+__XCONFIGFILE__ = @__XCONFIGFILE__@
+abi_ansic = @abi_ansic@
+abi_extension = @abi_extension@
+abi_font = @abi_font@
+abi_videodrv = @abi_videodrv@
+abi_xinput = @abi_xinput@
+abs_builddir = @abs_builddir@
+abs_srcdir = @abs_srcdir@
+abs_top_builddir = @abs_top_builddir@
+abs_top_srcdir = @abs_top_srcdir@
+ac_ct_CC = @ac_ct_CC@
+ac_ct_CXX = @ac_ct_CXX@
+ac_ct_F77 = @ac_ct_F77@
+am__include = @am__include@
+am__leading_dot = @am__leading_dot@
+am__quote = @am__quote@
+am__tar = @am__tar@
+am__untar = @am__untar@
+bindir = @bindir@
+build = @build@
+build_alias = @build_alias@
+build_cpu = @build_cpu@
+build_os = @build_os@
+build_vendor = @build_vendor@
+builddir = @builddir@
+datadir = @datadir@
+datarootdir = @datarootdir@
+docdir = @docdir@
+driverdir = @driverdir@
+dvidir = @dvidir@
+exec_prefix = @exec_prefix@
+extdir = @extdir@
+ft_config = @ft_config@
+host = @host@
+host_alias = @host_alias@
+host_cpu = @host_cpu@
+host_os = @host_os@
+host_vendor = @host_vendor@
+htmldir = @htmldir@
+includedir = @includedir@
+infodir = @infodir@
+install_sh = @install_sh@
+launchagentsdir = @launchagentsdir@
+libdir = @libdir@
+libexecdir = @libexecdir@
+localedir = @localedir@
+localstatedir = @localstatedir@
+logdir = @logdir@
+mandir = @mandir@
+mkdir_p = @mkdir_p@
+moduledir = @moduledir@
+oldincludedir = @oldincludedir@
+pdfdir = @pdfdir@
+prefix = @prefix@
+program_transform_name = @program_transform_name@
+psdir = @psdir@
+sbindir = @sbindir@
+sdkdir = @sdkdir@
+sharedstatedir = @sharedstatedir@
+srcdir = @srcdir@
+sysconfdir = @sysconfdir@
+target_alias = @target_alias@
+top_build_prefix = @top_build_prefix@
+top_builddir = @top_builddir@
+top_srcdir = @top_srcdir@
+xglmoduledir = @xglmoduledir@
+xpconfigdir = @xpconfigdir@
+EXTRA_DIST = \
+	DebuggingHints \
+	Domain.note \
+	RAC.Notes \
+	Registry \
+	exa-driver.txt \
+	README.DRIcomp
+
+all: all-am
+
+.SUFFIXES:
+$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am  $(am__configure_deps)
+	@for dep in $?; do \
+	  case '$(am__configure_deps)' in \
+	    *$$dep*) \
+	      cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \
+		&& exit 0; \
+	      exit 1;; \
+	  esac; \
+	done; \
+	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign  hw/xfree86/doc/devel/Makefile'; \
+	cd $(top_srcdir) && \
+	  $(AUTOMAKE) --foreign  hw/xfree86/doc/devel/Makefile
+.PRECIOUS: Makefile
+Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
+	@case '$?' in \
+	  *config.status*) \
+	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
+	  *) \
+	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
+	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
+	esac;
+
+$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
+	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+
+$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
+	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
+	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+
+mostlyclean-libtool:
+	-rm -f *.lo
+
+clean-libtool:
+	-rm -rf .libs _libs
+tags: TAGS
+TAGS:
+
+ctags: CTAGS
+CTAGS:
+
+
+distdir: $(DISTFILES)
+	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
+	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
+	list='$(DISTFILES)'; \
+	  dist_files=`for file in $$list; do echo $$file; done | \
+	  sed -e "s|^$$srcdirstrip/||;t" \
+	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
+	case $$dist_files in \
+	  */*) $(MKDIR_P) `echo "$$dist_files" | \
+			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
+			   sort -u` ;; \
+	esac; \
+	for file in $$dist_files; do \
+	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
+	  if test -d $$d/$$file; then \
+	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
+	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
+	      cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
+	    fi; \
+	    cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
+	  else \
+	    test -f $(distdir)/$$file \
+	    || cp -p $$d/$$file $(distdir)/$$file \
+	    || exit 1; \
+	  fi; \
+	done
+check-am: all-am
+check: check-am
+all-am: Makefile
+installdirs:
+install: install-am
+install-exec: install-exec-am
+install-data: install-data-am
+uninstall: uninstall-am
+
+install-am: all-am
+	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
+
+installcheck: installcheck-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
+	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
+	  `test -z '$(STRIP)' || \
+	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
+mostlyclean-generic:
+
+clean-generic:
+
+distclean-generic:
+	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
+
+maintainer-clean-generic:
+	@echo "This command is intended for maintainers to use"
+	@echo "it deletes files that may require special tools to rebuild."
+clean: clean-am
+
+clean-am: clean-generic clean-libtool mostlyclean-am
+
+distclean: distclean-am
+	-rm -f Makefile
+distclean-am: clean-am distclean-generic
+
+dvi: dvi-am
+
+dvi-am:
+
+html: html-am
+
+info: info-am
+
+info-am:
+
+install-data-am:
+
+install-dvi: install-dvi-am
+
+install-exec-am:
+
+install-html: install-html-am
+
+install-info: install-info-am
+
+install-man:
+
+install-pdf: install-pdf-am
+
+install-ps: install-ps-am
+
+installcheck-am:
+
+maintainer-clean: maintainer-clean-am
+	-rm -f Makefile
+maintainer-clean-am: distclean-am maintainer-clean-generic
+
+mostlyclean: mostlyclean-am
+
+mostlyclean-am: mostlyclean-generic mostlyclean-libtool
+
+pdf: pdf-am
+
+pdf-am:
+
+ps: ps-am
+
+ps-am:
+
+uninstall-am:
+
+.MAKE: install-am install-strip
+
+.PHONY: all all-am check check-am clean clean-generic clean-libtool \
+	distclean distclean-generic distclean-libtool distdir dvi \
+	dvi-am html html-am info info-am install install-am \
+	install-data install-data-am install-dvi install-dvi-am \
+	install-exec install-exec-am install-html install-html-am \
+	install-info install-info-am install-man install-pdf \
+	install-pdf-am install-ps install-ps-am install-strip \
+	installcheck installcheck-am installdirs maintainer-clean \
+	maintainer-clean-generic mostlyclean mostlyclean-generic \
+	mostlyclean-libtool pdf pdf-am ps ps-am uninstall uninstall-am
+
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/xorg-server/hw/xfree86/doc/devel/RAC.Notes b/xorg-server/hw/xfree86/doc/devel/RAC.Notes
new file mode 100644
index 000000000..0aec9d795
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/RAC.Notes
@@ -0,0 +1,696 @@
+I. Abstract 
+===========
+
+Graphics devices are accessed thru ranges in I/O or memory space. While
+most modern graphics  devices allow relocation of such  ranges many of
+them still require the use  of well established interfaces such as VGA
+memory  and IO  ranges or  8514/A  IO ranges.   Up to  version 3.3  of
+XFree86 only a single graphics  device could be driven. Therfore there
+was no need  to address the issue of sharing such  memory or I/O ranges
+among several devices. Starting with version 4.0 XFree86 is capable of
+driving more  than one graphics interface in  a multi-head environment.
+Therefore  a mechanism  needed to  be  designed which  was capable  of
+controlling the sharing  the access to memory and  I/O ranges.  In this
+document  we describe  to use  of  the RAC  (Resource Access  Control)
+system in the XFree86 server which provides the service of controlling
+access to interface resources.
+
+II. Introduction
+================
+
+Terms and definitions:
+
+II.1. Bus
+---------
+
+'Bus' is ambiguous as it is used for different things: It may refer to
+physical incompatible  extension connectors in a  computer system. The
+RAC system  knows two such systems: The  ISA bus and the  PCI bus. (On
+the software  level EISA, MC and  VL buses are  currently treated like
+ISA buses). 'Bus' may always  refer to logically different entities on
+a single bus  system which are connected via bridges.  A PCI system may
+have several  distinct PCI  buses connecting  each other  by PCI-PCI
+bridges or to the host CPU by HOST-PCI bridges.
+
+Systems that host  more than one bus system  link these together using
+bridges. Bridges  are a  concern to  RAC as they  might block  or pass
+specific  resources.  PCI-PCI  bridges  may  be set  up  to  pass  VGA
+resources to the  secondary bus. PCI-ISA buses pass  any resources not
+decoded on the primary PCI bus  to the ISA bus. This way VGA resources
+(although  exclusive on  the ISA  bus) can  be shared  by ISA  and PCI
+cards.  Currently HOST-PCI bridges are not yet handled by RACY as they
+require specific drivers.
+
+II.2. Entity 
+------------
+
+The  smallest  independently  addressable  unit  on a  system  bus  is
+referred to  as an entity. So far  we know ISA and  PCI entities.  PCI
+entities can be  located on the PCI bus by an  unique ID consisting of
+the bus, card and function number.
+
+II.3. Resource
+--------------
+
+ 'Resource' refers to  a range of memory or  I/O addresses an entity
+can decode.
+
+If  a device is  capable of  disabling this  decoding the  resource is
+called  sharable. For  PCI devices  a  generic method  is provided  to
+control resource decoding. Other devices will have to provide a device
+specific function to control decoding.
+
+If  the  entity is  capable  of decoding  this  range  at a  different
+location this resource is considered relocatable. Resource which start
+at a specific address and  occupy a single continuous range are called
+block resources.
+
+Alternatively resource  addresses can  be decoded in  a way  that they
+satisfy the condition: 
+
+			address & mask == base
+
+with  base &  mask ==  base.  Resources  addressed in  such a  way are
+considered sparse resources.
+
+
+II.4. Server States
+------------------
+
+The resource access control system  knows two server states: the SETUP
+and the  OPERATING state. The setup  state is entered  whenever a mode
+change takes place  or the server exits or  does VT switching.  During
+this  state any  entity  resource is  under  resource access  control.
+During  OPERATING  state  only  those entities  are  controlled  which
+actually  have  shared  resources  that  conflict  with  others.   The
+determination which entity is to  be placed under RAC during OPERATING
+state  takes   place  after  ScreenInit()  during   the  first  server
+generation.  This doesn't apply if  only one screen is active: in this
+case no RAC is needed and  the screen is simply left enabled while the
+server is active.
+
+
+III. Theory of operation
+========================
+
+III.1. General
+--------------
+
+The common  level has knowledge  of generic access  control mechanisms
+for devices on certain bus systems  (currently the PCI bus) as well as
+of   methods   to   enable    or   disable   access   to   the   buses
+itself. Furthermore it can  access information on resources decoded by
+these devices and if necessary modify it.
+
+When first  starting the Xserver collects all  this information, saves
+it for restoration checks it for consistency and if necessary corrects
+it.  Finally it disables  all resources  on a  generic level  prior to
+calling any driver function.
+
+ The  user should  provide a  device  section in  XF86Config for  each
+graphics device  installed in  his system. Each  such entity  which is
+never to  be used as X display  device might be marked  as inactive by
+adding the keyword "Inactive" to the device section.
+
+When the Probe() function of each driver is called the device sections
+are matched against  the devices found in the  system.  The driver may
+probe devices at this stage  that cannot be identified by using device
+independent methods. Access to all resources that can be controlled in
+a  device independent way  is disabled.   The Probe()  function should
+register all  non-relocatable resources at  this stage. If  a resource
+conflict  is found between  exclusive resources  the driver  will fail
+immediately.  Optionally  the driver  might  specify an  EntityInit(),
+EntityLeave() and EntityEnter() function.
+
+EntityInit() can be used to  disable any shared resources that are not
+controlled by the generic access control functions. It is called prior
+to the PreInit  phase regardless if an entity is  active or not.  When
+calling  the EntityInit(),  EntityEnter() and  EntityLeave() functions
+the  common level  will  disable access  to  all other  entities on  a
+generic  level. Since  the common  level  has no  knowledge of  device
+specific  methods  to  disable   access  to  resources  it  cannot  be
+guaranteed that certain resources are  not decoded by any other entity
+until  the EntityInit()  or EntityEnter()  phase is  finished.  Device
+drivers should  therefore register all those resources  which they are
+going to  disable.  If  these resources  are never to  be used  by any
+driver  function they may  be flagged  'ResInit' so  that they  can be
+removed  from  the resource  list  after  processing all  EntityInit()
+functions.   EntityEnter() should  disable decoding  of  all resources
+which are not registered as exclusive and which are not handled by the
+generic  access  control  in  the  common level.   The  difference  to
+EntityInit()  is  that the  latter  one  is  only called  once  during
+lifetime of the server.  It can  therefore be used to set up variables
+prior  to  disabling  resources.   EntityLeave()  should  restore  the
+original state when exiting the server or switching to a different vt.
+It also needs to disable device specific access functions if they need
+to be  disabled on server exit or  VT switch. The default  state is to
+enable them before giving up the VT.
+
+In PreInit() phase each driver  should check if any sharable resources
+it has registered during Probe()  has been denied and take appropriate
+action which could simply be to  fail. If it needs to access resources
+it  has disabled during  EntitySetup() it  can do  so provided  it has
+registered  these   and  will  disable  them   before  returning  from
+PreInit(). This  also applies to all other  driver functions.  Several
+functions  are provided  to request  resource ranges,  register these,
+correct PCI config  space and add replacements for  the generic access
+functions.  Resources  may be  marked  'disabled'  or 'unused'  during
+OPERATING  stage.  Although  these steps  could also  be  performed in
+ScreenInit(), this is not desirable.
+
+Following  PreInit() phase  the  common level  determines if  resource
+access control is needed.  This is the case if more than one screen is
+used. If necessary the RAC  wrapper module is loaded.  In ScreenInit()
+the  drivers can  decide  which  operations need  to  be placed  under
+RAC. Available are the frame buffer operations, the pointer operations
+and  the colormap  operations. Any  operation that  requires resources
+which might  be disabled during OPERATING  state should be  set to use
+RAC.  This can be specified separately for memory and IO resources.
+
+When ScreenInit() phase is done  the common level will determine which
+shared resources  are requested  by more than  one driver and  set the
+access functions accordingly.  This is done following these rules:
+
+a. The sharable resources registered  by each entity are compared.  if
+   a resource is registered by more than one entity the entity will be
+   marked to need to share this resources type (IO or MEM).
+
+b. A resource marked 'disabled' during OPERATING state will be ignored
+   entirely.
+
+c. A resource marked 'unused'  will only conflicts with an overlapping
+   resource of an other entity if the second is actually in use during
+   OPERATING state.
+
+d. If  an 'unused' resource was  found to conflict  however the entity
+   does not  use any other resource  of this type  the entire resource
+   type will be disabled for that entity.
+ 
+The driver  has the choice among  different ways to  control access to
+certain resources:
+
+a. It can relay on the  generic access functions. This is probably the
+   most  common case.  Here  the  driver only  needs  to register  any
+   resource it is going to use.
+
+b.  It  can replace  the generic access  functions by  driver specific
+   ones. This  will mostly  be used in  cases where no  generic access
+   functions are available.  In this  case the driver has to make sure
+   these  resources are  disabled when  entering the  PreInit() stage.
+   Since  the replacement  functions are  registered in  PreInit() the
+   driver will  have to enable these  resources itself if  it needs to
+   access  them during  this state.   The  driver can  specify if  the
+   replacement  functions  can  control  memory and/or  I/O  resources
+   separately.
+
+c. The  driver can  enable resources itself  when it needs  them. Each
+   driver function enabling them needs  to disable them before it will
+   return. This should  be used if a resource  which can be controlled
+   in a device dependent way is only required during SETUP state. This
+   way it can be marked 'unused' during OPERATING state.
+
+A  resource which  is  decoded during  OPERATING  state however  never
+accessed by the driver should be marked unused.
+   
+Since  access   switching  latencies  are  an   issue  during  Xserver
+operation,  the  common  level  attempts  to minimize  the  number  of
+entities that  need to  be placed under  RAC control.  When  a wrapped
+operation  is called,  the  EnableAccess() function  is called  before
+control  is passed  on.  EnableAccess()  checks if  a screen  is under
+access control. If not it just establishes bus routing and returns. If
+the screen needs to be under access control, EnableAccess() determines
+which resource  types (MEM,IO)  are required.  Then  it tests  if this
+access is  already established.   If so it  simply returns. If  not it
+disables  the  currently established  access,  fixes  bus routing  and
+enables access to all entities registered for this screen.
+
+Whenever a  mode switch or a  vt-switch is performed  the common level
+will return to SETUP state.
+
+III.3. Resource Types
+---------------------
+
+Resource  have  certain properties.  When  registering resources  each
+range is  accompanied by a flag  consisting of the or'ed  flags of the
+different  properties the  resource has.  Each resource  range  may be
+classified according to 
+
+- its  physical properties ie. if it addresses
+    memory (ResMem)  or 
+    I/O space (ResIo), 
+- if it addresses a 
+    block (ResBlock) or 
+    sparse (ResSparse) 
+  range, 
+- its access properties.  
+
+There are two known access properties: 
+
+- ResExclusive
+  for resources which may not be shared with any other device and 
+- ResShared 
+  for resources which can be disabled and therefore can be shared.  
+
+If  it is  desirable to  test a  resource against  any type  a generic
+access type  'ResAny' is  provided. If this  is set the  resource will
+conflict  with any  resource of  a different  entity  intersecting its
+range.  Further it can be specified that a resource is decoded however
+never  used during  any stage  (ResUnused) or  during  OPERATING state
+(ResUnusedOpr). A resource only visible during the init functions (ie.
+EntityInit(),  EntityEnter() and  EntityLeave()  should be  registered
+with  the  flag  'ResInit'.   A  resource  that  might  conflict  with
+background resource  ranges may be flagged with  'ResBios'. This might
+be useful when registering resources  ranges that were assigned by the
+system Bios.
+
+Several  predefined resource lists  are available  for VGA  and 8514/A
+resources in common/sf86Resources.h.
+
+IV. Available Functions
+=======================
+
+The functions provided for resource management will be listed in order
+of use in the driver.
+
+IV.1. Probe phase
+-----------------
+
+In this stage each driver detects those resources it is able to drive,
+creates an  entity record for each of  them, registers non-relocatable
+resources and allocates screens and adds the resources to screens.
+
+Two helper functions are provided  for matching device sections in the
+XF86Config file to the devices:
+
+   int xf86MatchPciInstances(const char *driverName, int vendorID, 
+ 		             SymTabPtr chipsets, PciChipsets *PCIchipsets,
+		             GDevPtr *devList, int numDevs, DriverPtr drvp,
+		             int **foundEntities);
+
+   int xf86MatchIsaInstances(const char *driverName, SymTabPtr chipsets,
+			     IsaChipsets *ISAchipsets, DriverPtr drvp,
+			     FindIsaDevProc FindIsaDevice, GDevPtr *devList,
+			     int numDevs, int **foundEntities);
+
+Both functions return the number of matched entities and their indices
+in foundEntities list.
+
+They make use of several  sub functions which are also available on the
+driver level:
+
+   Bool xf86ComparePciBusString(const char *busID, int bus, 
+                                int device, int func);
+
+and 
+
+   Bool xf86ParseIsaBusString(const char *busID);
+
+are called to interpret the busID in the device section. The functions:
+
+   int xf86ClaimPciSlot(int bus, int device, int func, DriverPtr drvp,
+		        int chipset, GDevPtr dev, Bool active);
+
+   int xf86ClaimIsaSlot(DriverPtr drvp, int chipset, GDevPtr dev, Bool
+	 	        active);
+
+are  used  to  allocate   the  entities  and  initialize  their  data
+structures.  Both functions  return the  index of  the  newly allocated
+entity record or (-1) should  the function fail. Before probing an ISA
+card
+
+   Bool xf86IsPrimaryIsa();
+
+gets called to determine if the primary card was not detected on the
+PCI bus.
+
+Two helper functions are provided to aid configuring entities:
+
+   Bool xf86ConfigActivePciEntity(ScrnInfoPtr pScrn, int entityIndex,
+			          PciChipsets *p_chip, resList res,
+			          EntityProc init, EntityProc enter,
+			          EntityProc leave, pointer private);
+   Bool xf86ConfigActiveIsaEntity(ScrnInfoPtr pScrn, int entityIndex,
+			          IsaChipsets *i_chip, resList res,
+			          EntityProc init, EntityProc enter,
+			          EntityProc leave, pointer private); 
+
+They  are used  to register  the init/enter/leave  functions described
+above as well as the  non-relocatable resources. Generally the list of
+fixed resources  is obtained from the  Isa/PciChipsets lists.  However
+an additional list  of resources may be passed.  Generally this is not
+required. The init/enter/leave functions have to be of type
+
+  typedef void (*EntityProc)(int entityIndex,pointer private);
+
+They are  passed the entity index  and a pointer to  a private scratch
+area. This  are can be  set up during  Probe() and its address  can be
+passed  to xf86ConfigActiveIsaEntity()  xf86ConfigActivePciEntity() as
+the last argument.
+
+These helper functions use: 
+
+    void xf86ClaimFixedResources(resList list, int entityIndex);
+
+  To register  the non relocatable  resources which cannot  be disabled
+  and which  therefore would cause  the server to fail  immediately if
+  they  were found to  conflict. It  also records  non-relocatable but
+  sharable resources for processing after the Probe() phase.
+
+    Bool xf86SetEntityFuncs(int entityIndex, EntityProc init,
+	 	 	    EntityProc enter, EntityProc leave, pointer);
+
+  This function registers  the init/enter/leave() functions along with
+  the pointer to their private area to the entity.
+
+    void xf86AddEntityToScreen(ScrnInfoPtr pScrn, int entityIndex);
+ 
+  adds the entity to the screen.
+
+These functions are  also available on the driver  level.  A detailed
+Probe() function  is listed below. For  most drivers this  can be used
+with little change.
+
+Please  note  that  VGA  resources  have  to  be  claimed  in  Probe()
+phase. Otherwise they are not routed to the bus.
+
+IV.2. PreInit() phase
+---------------------
+
+During  this  phase  the  remaining  resource  should  be  registered.
+PreInit() should call
+
+  EntityInfoPtr xf86GetEntityInfo(int entityIndex);
+
+To obtain a pointer to an  EntityInfoRec for each entity it is able to
+drive and check if any  resource are listed in 'resources'. These have
+been rejected in  the post-Probe() phase. The driver  should decide if
+it can continue without using these or if it should fail.  The pointer
+to the EntityInfoRec should be freed if not needed any more.
+
+Several functions are provided to simplify resource registration:
+
+  Bool xf86IsEntityPrimary(int entityIndex);
+
+is used to determine if the  entity is the display device that is used
+during boot-up and text mode.
+
+  Bool xf86IsScreenPrimary(int scrnIndex);
+
+finds  out if the  primary entity  is registered  for the  screen with
+specified index.
+
+  pciVideoPtr xf86GetPciInfoForEntity(int entityIndex);
+
+returns a pointer  to the pciVideoRec of the  specified entity. If the
+entity is not a PCI device NULL is returned.
+
+The primary function for registration of resources is
+
+  resPtr xf86RegisterResources(int entityIndex, resList list, int access);
+
+it tries to register the resources in 'list'. If list is NULL it tries
+to determine the resources automatically. This only works for entities
+that  provide a  generic  way to  read  out the  resource ranges  they
+decode. So far  this is only the case for PCI  devices. By default the
+PCI resources are registered as shared (ResShared) if the driver wants
+to set a  different access type it can do so  by specifying the access
+flags in  the third argument.  A value of  0 means to use  the default
+settings.  If  for any  reason  the resource  broker  is  not able  to
+register some  of the requested  resources the function will  return a
+pointer to a list of the failed ones. In this case the driver may move
+the resource to different locations.  In case of PCI bus entities this
+is done by passing the list of failed resources to
+
+  resPtr xf86ReallocatePciResources(int entityIndex, resPtr pRes);
+
+this function returns a list  of reallocated resource. This list needs
+to be  passed to xf86RegisterResources()  again to be  registered with
+the broker.
+
+Two functions are provided to obtain a resource range of a given type:
+
+  resRange xf86GetBlock(long type, memType size,
+		        memType window_start, memType window_end,
+		        memType align_mask, resPtr avoid);
+  resRange xf86GetSparse(long type,  unsigned long fixed_bits,
+		         unsigned long decode_mask, unsigned long address_mask,
+		         resPtr avoid);
+
+The first  one tries  to find a  block range  of size 'size'  and type
+'type'  in a  window bound  by  window_start and  window_end with  the
+alignment specified  in alignment mask. Optionally a  list of resource
+ranges which should  be avoided inside this window  can be passed.  On
+failure it will return a zero range of type 'ResEnd'.
+
+The latter function does the same for sparse resources. A spares range
+is  determined by  to  parameters: the  mask  and the  base value.  An
+address satisfying
+
+			mask & address == base
+
+belongs  to the specific  spares range.  'mask' and  'base' themselves
+have to satisfy:
+
+			 mask & base == base.
+
+Here three values  have to be specified: the  address mask which marks
+all bits of the mask part  of the address, the decode_mask which masks
+out the bits  which are hard coded and are  therefore not available for
+relocation and  the values  of the fixed  bits. The function  tries to
+find a base that satisfies  the given condition. If the function fails
+it will return  a zero range of type 'ResEnd'.  Optionally it might be
+passed a list of resource ranges to avoid.
+
+Certain PCI devices  are broken in the sense  that they return invalid
+size information for  a certain resource. In this  case the driver can
+supply  the  correct  size  and  make sure  that  the  resource  range
+allocated  for the  card is  large enough  to hold  the  address range
+decoded by the card. The function:
+
+  Bool xf86FixPciResource(int entityIndex, unsigned int prt, CARD32 alignment,
+	 		  long type);
+
+is used  for that. The  parameter prt contains  the number of  the PCI
+base register that needs to be  modified. A value of 6 refers to the
+BIOS  base   register.  The  size   is  specified  in   the  alignment
+register. Since  PCI resources need to  span an integral  range of the
+size 2^n  the alignment  also specifies the  number of  addresses that
+will be decoded.  If the driver  specifies a type mask it can override
+the default type for PCI  resources which is 'ResShared'. The resource
+broker needs  to know  that to find  a matching resource  range.  This
+function should be called before calling xf86RegisterResources().
+
+  Bool xf86CheckPciMemBase(pciVideoPtr pPci, unsigned long base);
+
+checks that the memory base value specified in base matches one of the
+PCI base address register values for the given PCI device.
+
+The driver  may replace  the generic access  control functions  for an
+entity by it's own ones.
+
+  void xf86SetAccessFuncs(EntityInfoPtr pEnt, xf86SetAccessFuncPtr funcs,
+			xf86SetAccessFuncPtr oldFuncs);
+
+  with:
+
+  typedef struct {
+      xf86AccessPtr mem;
+      xf86AccessPtr io;
+      xf86AccessPtr io_mem;
+   } xf86SetAccessFuncRec, *xf86SetAccessFuncPtr;
+
+is used  for that. The  driver can pass  three functions: one  for I/O
+access,  one for memory  access and  one for  combined memory  and I/O
+access.   If  the memory  access  and  combined  access functions  are
+identical the  common level assumes  that the memory access  cannot be
+controlled independently of I/O access, if the I/O access function and
+the combined access functions are the  same it is assumed that I/O can
+not  be  controlled independently.   If  memory  and  I/O have  to  be
+controlled together  all three  values should be  the same.  If  a non
+NULL value is passed as third argument it is interpreted as an address
+where to store  the old access records. If the  third argument is NULL
+it will  be assumed that the  generic access should  be enabled before
+replacing the  access functions.  Otherwise  it will be  disabled. The
+driver may enable them itself  using the returned values. It should do
+this from his  replacement access functions as the  generic access may
+be disabled by  the common level on certain  occasions. If replacement
+functions  are  specified  they  must  control all  resources  of  the
+specific type registered for the entity.
+
+To find out if specific resource range is conflicting with another
+resource
+
+  memType xf86ChkConflict(resRange *rgp, int entityIndex);
+
+may be called. If a non-zero value is returned a conflict is found.
+
+  resPtr xf86SetOperatingState(resList list, int entityIndex, int mask);
+
+is used to set the state of a resource during OPERATING state.  'list'
+holds a list  to which 'mask' is to be  applied.  The parameter 'mask'
+may have the value  'ResUnusedOpr' and 'ResDisableOpr'.  The first one
+should be used if a  resource isn't used during OPERATING state however
+decoded by the device while the latter one indicates that the resource
+is not decoded  during OPERATING state. Note that  the resource ranges
+have to match those specified during registration. If a range has been
+specified  starting at A  and ending  at B  and suppose  C us  a value
+satisfying A < C  < B one may not specify the  resource range (A,B) by
+splitting it into two ranges (A,C) and (C,B).
+
+Two functions are provided for special cases:
+
+  void xf86RemoveEntityFromScreen(ScrnInfoPtr pScrn, int entityIndex);
+
+may be used  to remove an entity from a screen.  This only makes sense
+if a screen has  more than one entity assigned or the  screen is to be
+deleted. No test is made if the screen has any entities left.
+
+  void xf86DeallocateResourcesForEntity(int entityIndex, long type);
+
+deallocates all  resources of  a given type  registered for  a certain
+entity from the resource broker list.
+
+IV.3. ScreenInit() phase
+------------------------
+
+Setting up  the rac flags  is all that  remains to do  in ScreenInit()
+phase (Note that these flags might also be set up in PreInit() phase).
+The  ScrnInfoRec  has  separate  flags  for  memory  and  PIO  access:
+racIoFlags and  racMemFlags. They specifies  which graphics operations
+might require  the use of resources  which might be  disabled for some
+reason.  Note that even exclusive  resources might be disabled if they
+are disabled along with shared  resources. For example if a driver has
+registered the  VGA PIO  resources and lets  the common  level disable
+these by disabling PIO access  in PCI config space (the standard way),
+exclusive PCI PIO ranges will  also be disabled.  Therefore the driver
+has to flag any operations  requiring PCI PIO resources in racIoFlags.
+The avaliable flags are defined in rac/xf86RAC.h.  Available are:
+
+ RAC_FB       for framebuffer operations (including hw acceleration)
+ RAC_CURSOR   for Cursor operations
+              (??? I'm not sure if we need this for SW cursor it depends
+              on which level the sw cursor is drawn)
+ RAC_COLORMAP for colormap operations
+ RAC_VIEWPORT for the call to RACAdjustFrame()
+
+The flags are or'ed.
+
+V. Appendix
+===========
+
+A. Sample Probe() Function
+--------------------------
+
+static Bool
+XXXProbe(DriverPtr drv, int flags)
+{
+    Bool foundScreen = FALSE;
+    int numDevSections, numUsed;
+    GDevPtr *devSections;
+    int *usedChips;
+    int i;
+    
+    /*
+     * Find the config file Device sections that match this
+     * driver, and return if there are none.
+     */
+    if ((numDevSections = xf86MatchDevice(CHIPS_DRIVER_NAME,
+					  &devSections)) <= 0) {
+	return FALSE;
+    }
+    /* PCI BUS */
+    /* test if PCI bus present */
+    if (xf86GetPciVideoInfo() ) {
+    /* match PCI instances with ones supported by the driver */
+       	numUsed = xf86MatchPciInstances(XXX_NAME, PCI_VENDOR_XXX,
+					XXXChipsets, XXXPCIchipsets, 
+					devSections,numDevSections, drv,
+					&usedChips);
+	if (numUsed > 0) {
+	    for (i = 0; i < numUsed; i++) {
+	    		    /* Allocate a ScrnInfoRec  */
+                ScrnInfoPtr pScrn = xf86AllocateScreen(drv,0);
+		pScrn->driverVersion = VERSION;
+		pScrn->driverName    = XXX_DRIVER_NAME;
+		pScrn->name          = XXX_NAME;
+		pScrn->Probe         = XXXProbe;
+		pScrn->PreInit       = XXXPreInit;
+		pScrn->ScreenInit    = XXXScreenInit;
+		pScrn->SwitchMode    = XXXSwitchMode;
+		pScrn->AdjustFrame   = XXXAdjustFrame;
+		pScrn->EnterVT       = XXXEnterVT;
+		pScrn->LeaveVT       = XXXLeaveVT;
+		pScrn->FreeScreen    = XXXFreeScreen;
+		pScrn->ValidMode     = XXXValidMode;
+		foundScreen = TRUE;
+                 /* add screen to entity */
+		 xf86ConfigActivePciEntity(pScrn,usedChips[i],XXXPCIchipsets,
+		    		           NULL,NULL,NULL,NULL,NULL);
+	    }
+	}
+    }
+
+    /* Isa Bus */
+    numUsed = xf86MatchIsaInstances(XXX_NAME,XXXChipsets,XXXISAchipsets,
+				     drv,chipsFindIsaDevice,devSections,
+				     numDevSections,&usedChips);
+    if(numUsed >= 0)
+	for (i = 0; i < numUsed; i++) {
+	    ScrnInfoPtr pScrn = xf86AllocateScreen(drv,0);
+	  
+	    pScrn->driverVersion = VERSION;
+	    pScrn->driverName    = XXX_DRIVER_NAME;
+	    pScrn->name          = XXX_NAME;
+	    pScrn->Probe         = XXXProbe;
+	    pScrn->PreInit       = XXXPreInit;
+	    pScrn->ScreenInit    = XXXScreenInit;
+	    pScrn->SwitchMode    = XXXSwitchMode;
+	    pScrn->AdjustFrame   = XXXAdjustFrame;
+	    pScrn->EnterVT       = XXXEnterVT;
+	    pScrn->LeaveVT       = XXXLeaveVT;
+	    pScrn->FreeScreen    = XXXFreeScreen;
+	    pScrn->ValidMode     = XXXValidMode;
+	    foundScreen = TRUE;
+	    xf86ConfigActiveIsaEntity(pScrn,usedChips[i],XXXISAchipsets,
+	   			      NULL,NULL,NULL,NULL,NULL);
+	}
+    xfree(devSections);
+    return foundScreen;
+}
+
+B. Porting Issues
+-----------------
+
+Here are some hints on porting code developed for RAC 1 to RAC 2.
+
+1. a. Initialization of RAC is now entirely done on the common level.
+      Therefore the call to xf86RACInit() can be removed. 
+
+   b. Also there is no need for the racSymbols list. 
+
+   c. LoadSubModule(..,rac) should be removed.
+
+   d. racSymbols should be removed from LoaderRequestSymList(racSymbols,..)
+
+2. a. if the driver uses the predefined resource lists xf86Resources.h
+      needs to be included.
+
+   b. RES_VGA should be changed to RES_EXCLUSIVE_VGA
+
+3. The device list now belongs to the EntityInfoRec. 
+   Change pScrn->device to xxx->pEnt->device.
+
+4. Rewrite the Probe() function. The example given above should work
+   as a guideline.
+
+5. Register all necessary resources in PreInit() by calling 
+   xf86RegisterResources().
+
+6. If applicable set the operating state of the registered resources 
+   by calling xf86SetOperatingState(). This should be done during
+   PreInit(). If necessary it might still be done in ScreenInit()
+
+7. Set up the racIoFlags and racMemFlags.
+
+
+ LocalWords:  ISA
diff --git a/xorg-server/hw/xfree86/doc/devel/README.DRIcomp b/xorg-server/hw/xfree86/doc/devel/README.DRIcomp
new file mode 100644
index 000000000..89f40a759
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/README.DRIcomp
@@ -0,0 +1,556 @@
+                            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/devel/Registry b/xorg-server/hw/xfree86/doc/devel/Registry
new file mode 100644
index 000000000..1fec230e8
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/Registry
@@ -0,0 +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")
+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
+SendDragEvents            B     I    Send drag 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/devel/exa-driver.txt b/xorg-server/hw/xfree86/doc/devel/exa-driver.txt
new file mode 100644
index 000000000..048307ee7
--- /dev/null
+++ b/xorg-server/hw/xfree86/doc/devel/exa-driver.txt
@@ -0,0 +1,94 @@
+Adding EXA support to your X.Org video driver
+---------------------------------------------
+EXA (for EXcellent Architecture or Ex-kaa aXeleration Architecture or
+whatever) aims to extend the life of the venerable XFree86 video drivers by
+introducing a new set of acceleration hooks that efficiently accelerate the X
+Render extension, including solid fills, blits within screen memory and to and
+from system memory, and Porter-Duff compositing and transform operations.
+
+Configuration
+-------------
+A new config file option, AccelMethod, should be added to your driver, to allow
+the user to select between the EXA and XAA acceleration APIs.
+
+Some drivers implement a per-instance useEXA flag to track whether EXA is
+active or not.  It can be helpful to also conditionalize XAA support with an
+ifdef so that it can easily be turned off/removed in the future.
+
+Setting the flag and checking for AccelMethod can be done in the driver's
+Options parsing routine.
+
+Loading EXA
+------------
+EXA drivers in the XFree86 DDX should use the loadable module loader to load
+the EXA core.  Careful versioning allows the EXA API to be extended without
+breaking the ABI for older versions of drivers.  Example code for loading EXA:
+
+static const char *exaSymbols[] = {
+    "exaDriverAlloc",
+    "exaDriverInit",
+    "exaDriverFini",
+    "exaOffscreenAlloc",
+    "exaOffscreenFree",
+    "exaGetPixmapOffset",
+    "exaGetPixmapPitch",
+    "exaGetPixmapSize",
+    "exaMarkSync",
+    "exaWaitSync",
+    NULL
+};
+
+	if (info->useEXA) {
+	    info->exaReq.majorversion = 2;
+	    info->exaReq.minorversion = 0;
+
+	    if (!LoadSubModule(pScrn->module, "exa", NULL, NULL, NULL,
+			       &info->exaReq, &errmaj, &errmin)) {
+		LoaderErrorMsg(NULL, "exa", errmaj, errmin);
+		return FALSE;
+	    }
+	    xf86LoaderReqSymLists(exaSymbols, NULL);
+	}
+
+EXA is then initialized using exaDriverAlloc and exaDriverInit.  See doxygen
+documentation for getting started there.
+
+Further documentation
+------------
+The EXA driver interface and public API is documented using doxygen in
+xserver/xorg/exa/.  To build the documentation, run:
+  doxygen -g
+  doxygen Doxyfile
+The resulting documentation will appear an html/index.html under the current
+directory.
+
+EXA initialization
+------------------
+Your driver's AccelInit routine must initialize an ExaDriverRec structure if
+EXA support is enabled, with appropriate error handling (i.e.  NoAccel and
+NoXvideo should be set to true if EXA fails to initialize for whatever
+reason).
+
+The AccelInit routine also needs to make sure that there's enough offscreen
+memory for certain operations to function, like Xvideo, which should advertise
+a maximum size no larger than can be dealt with given the amount of offscreen
+memory available.
+
+EXA and Xv
+----------
+Video support becomes easier with EXA since AllocateFBMemory can use
+exaOffscreenAlloc directly, freeing a previous area if necessary and
+allocating a new one.  Likewise, FreeFBMemory can call exaOffscreenFree.
+
+EXA teardown
+------------
+At screen close time, EXA drivers should call exaDriverFini with their screen
+pointer, free their EXADriver structure, and do any other necessary teardown.
+
+EXA misc.
+---------
+In many drivers, DGA support will need to be changed to be aware of the new
+EXA support.
+
+Send updates and corrections to Jesse Barnes <jbarnes@virtuousgeek.org> or
+just check them in if you have permission.