aboutsummaryrefslogtreecommitdiff
path: root/xorg-server/hw/xfree86/doc/devel
diff options
context:
space:
mode:
Diffstat (limited to 'xorg-server/hw/xfree86/doc/devel')
-rw-r--r--xorg-server/hw/xfree86/doc/devel/DebuggingHints192
-rw-r--r--xorg-server/hw/xfree86/doc/devel/Domain.note159
-rw-r--r--xorg-server/hw/xfree86/doc/devel/Makefile.am10
-rw-r--r--xorg-server/hw/xfree86/doc/devel/Makefile.in542
-rw-r--r--xorg-server/hw/xfree86/doc/devel/RAC.Notes696
-rw-r--r--xorg-server/hw/xfree86/doc/devel/README.DRIcomp556
-rw-r--r--xorg-server/hw/xfree86/doc/devel/Registry409
-rw-r--r--xorg-server/hw/xfree86/doc/devel/exa-driver.txt94
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-12 17:43:12 +0000