Checked in xorg-server-1.6.99.901

3 files changed, 8 insertions, 856 deletions

diff --git a/xorg-server/hw/xfree86/doc/devel/Domain.note b/xorg-server/hw/xfree86/doc/devel/Domain.note
deleted file mode 100644
index ce0812b22..000000000
--- a/xorg-server/hw/xfree86/doc/devel/Domain.note
+++ /dev/null
@@ -1,159 +0,0 @@
-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.in b/xorg-server/hw/xfree86/doc/devel/Makefile.in
index 390803a89..0071531af 100644
--- a/xorg-server/hw/xfree86/doc/devel/Makefile.in
+++ b/xorg-server/hw/xfree86/doc/devel/Makefile.in
@@ -57,6 +57,12 @@ CONFIG_HEADER = $(top_builddir)/include/do-not-use-config.h \
 	$(top_builddir)/include/version-config.h
 CONFIG_CLEAN_FILES =
 CONFIG_CLEAN_VPATH_FILES =
+AM_V_GEN = $(am__v_GEN_$(V))
+am__v_GEN_ = $(am__v_GEN_$(AM_DEFAULT_VERBOSITY))
+am__v_GEN_0 = @echo "  GEN   " $@;
+AM_V_at = $(am__v_at_$(V))
+am__v_at_ = $(am__v_at_$(AM_DEFAULT_VERBOSITY))
+am__v_at_0 = @
 SOURCES =
 DIST_SOURCES =
 DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
@@ -65,9 +71,9 @@ ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
 ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
 ALLOCA = @ALLOCA@
 AMTAR = @AMTAR@
+AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
 AM_MAKEFLAGS = @AM_MAKEFLAGS@
 APPLE_APPLICATIONS_DIR = @APPLE_APPLICATIONS_DIR@
-APPLE_APPLICATION_ID = @APPLE_APPLICATION_ID@
 APPLE_APPLICATION_NAME = @APPLE_APPLICATION_NAME@
 APP_MAN_DIR = @APP_MAN_DIR@
 APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
@@ -156,6 +162,7 @@ KDRIVE_LIBS = @KDRIVE_LIBS@
 KDRIVE_LOCAL_LIBS = @KDRIVE_LOCAL_LIBS@
 KDRIVE_PURE_INCS = @KDRIVE_PURE_INCS@
 KDRIVE_PURE_LIBS = @KDRIVE_PURE_LIBS@
+LAUNCHD_ID_PREFIX = @LAUNCHD_ID_PREFIX@
 LD = @LD@
 LDFLAGS = @LDFLAGS@
 LD_EXPORT_SYMBOLS_FLAG = @LD_EXPORT_SYMBOLS_FLAG@
diff --git a/xorg-server/hw/xfree86/doc/devel/RAC.Notes b/xorg-server/hw/xfree86/doc/devel/RAC.Notes
deleted file mode 100644
index 0aec9d795..000000000
--- a/xorg-server/hw/xfree86/doc/devel/RAC.Notes
+++ /dev/null
@@ -1,696 +0,0 @@
-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