Imported nx-X11-3.1.0-1.tar.gznx-X11/3.1.0-1

Summary: Imported nx-X11-3.1.0-1.tar.gz
Keywords:

Imported nx-X11-3.1.0-1.tar.gz
into Git repository

1 files changed, 2989 insertions, 0 deletions

diff --git a/nx-X11/programs/Xserver/hw/dmx/doc/dmx.txt b/nx-X11/programs/Xserver/hw/dmx/doc/dmx.txt
new file mode 100644
index 000000000..568c75178
--- /dev/null
+++ b/nx-X11/programs/Xserver/hw/dmx/doc/dmx.txt
@@ -0,0 +1,2989 @@
+  Distributed Multihead X design
+  Kevin E. Martin, David H. Dawes, and Rickard E. Faith
+
+  29 June 2004 (created 25 July 2001)
+
+  This document covers the motivation, background, design, and implemen-
+  tation of the distributed multihead X (DMX) system.  It is a living
+  document and describes the current design and implementation details
+  of the DMX system.  As the project progresses, this document will be
+  continually updated to reflect the changes in the code and/or design.
+  _C_o_p_y_r_i_g_h_t _2_0_0_1 _b_y _V_A _L_i_n_u_x _S_y_s_t_e_m_s_, _I_n_c_._, _F_r_e_m_o_n_t_, _C_a_l_i_f_o_r_n_i_a_.  _C_o_p_y_-
+  _r_i_g_h_t _2_0_0_1_-_2_0_0_4 _b_y _R_e_d _H_a_t_, _I_n_c_._, _R_a_l_e_i_g_h_, _N_o_r_t_h _C_a_r_o_l_i_n_a
+
+  ______________________________________________________________________
+
+  Table of Contents
+
+
+
+  1. Introduction
+     1.1 The Distributed Multihead X Server
+     1.2 Layout of Paper
+
+  2. Development plan
+     2.1 Bootstrap code
+     2.2 Input device handling
+     2.3 Output device handling
+        2.3.1 Initialization
+        2.3.2 Handling rendering requests
+     2.4 Optimizing DMX
+     2.5 DMX X extension support
+     2.6 Common X extension support
+     2.7 OpenGL support
+
+  3. Current issues
+     3.1 Fonts
+     3.2 Zero width rendering primitives
+     3.3 Output scaling
+     3.4 Per-screen colormaps
+
+  A. Background
+     A.1 Core input device handling
+        A.1.1 InitInput()
+        A.1.2 InitAndStartDevices()
+        A.1.3 devReadInput()
+        A.1.4 ProcessInputEvents()
+        A.1.5 DisableDevice()
+        A.1.6 CloseDevice()
+        A.1.7 LegalModifier()
+     A.2 Output handling
+        A.2.1 InitOutput()
+        A.2.2 AddScreen()
+        A.2.3 ScreenInit()
+        A.2.4 CloseScreen()
+        A.2.5 GC operations
+        A.2.6 Xnest
+        A.2.7 Shadow framebuffer
+     A.3 Xinerama
+        A.3.1 Xinerama-specific changes to the DIX code
+        A.3.2 Xinerama-specific changes to the MI code
+        A.3.3 Intercepted DIX core requests
+
+  B. Development Results
+     B.1 Phase I
+        B.1.1 Scope
+        B.1.2 Results
+        B.1.3 X Test Suite
+           B.1.3.1 Introduction
+           B.1.3.2 Expected Failures for a Single Head
+           B.1.3.3 Expected Failures for Xinerama
+           B.1.3.4 Additional Failures from Xdmx
+           B.1.3.5 Summary and Future Work
+        B.1.4 Fonts
+        B.1.5 Performance
+        B.1.6 Pixmaps
+     B.2 Phase II
+        B.2.1 Moving from XFree86 4.1.99.1 to 4.2.0.0
+        B.2.2 Global changes
+        B.2.3 XSync() Batching
+        B.2.4 Offscreen Optimization
+        B.2.5 Lazy Window Creation Optimization
+        B.2.6 Subdividing Rendering Primitives
+        B.2.7 Summary of x11perf Data
+        B.2.8 Profiling with OProfile
+        B.2.9 X Test Suite
+     B.3 Phase III
+        B.3.1 SHAPE
+        B.3.2 RENDER
+        B.3.3 XKEYBOARD
+        B.3.4 XInput
+        B.3.5 DPMS
+        B.3.6 Other Extensions
+     B.4 Phase IV
+        B.4.1 Moving to XFree86 4.3.0
+        B.4.2 Extensions
+           B.4.2.1 XC-MISC (supported)
+           B.4.2.2 Extended-Visual-Information (supported)
+           B.4.2.3 RES (supported)
+           B.4.2.4 BIG-REQUESTS (supported)
+           B.4.2.5 XSYNC (supported)
+           B.4.2.6 XTEST, RECORD, DEC-XTRAP (supported) and XTestExtension1 (not supported)
+           B.4.2.7 MIT-MISC (not supported)
+           B.4.2.8 SCREENSAVER (not supported)
+           B.4.2.9 GLX (supported)
+           B.4.2.10 RENDER (supported)
+           B.4.2.11 Summary
+        B.4.3 Additional Testing with the X Test Suite
+           B.4.3.1 XFree86 without XTEST
+           B.4.3.2 XFree86 with XTEST
+           B.4.3.3 Xdmx with XTEST, without Xinerama, without GLX
+           B.4.3.4 Xdmx with XTEST, with Xinerama, without GLX
+           B.4.3.5 Xdmx with XTEST, with Xinerama, with GLX
+           B.4.3.6 Conclusion
+        B.4.4 Dynamic Reconfiguration
+           B.4.4.1 Dynamic reconfiguration extension
+           B.4.4.2 Bounding box
+           B.4.4.3 Sample applications
+           B.4.4.4 Additional notes
+        B.4.5 Doxygen documentation
+        B.4.6 Valgrind
+        B.4.7 RATS
+
+
+  ______________________________________________________________________
+
+  11..  IInnttrroodduuccttiioonn
+
+  11..11..  TThhee DDiissttrriibbuutteedd MMuullttiihheeaadd XX SSeerrvveerr
+
+  Current Open Source multihead solutions are limited to a single
+  physical machine.  A single X server controls multiple display
+  devices, which can be arranged as independent heads or unified into a
+  single desktop (with Xinerama).  These solutions are limited to the
+  number of physical devices that can co-exist in a single machine
+  (e.g., due to the number of AGP/PCI slots available for graphics
+  cards).  Thus, large tiled displays are not currently possible.  The
+  work described in this paper will eliminate the requirement that the
+  display devices reside in the same physical machine.  This will be
+  accomplished by developing a front-end proxy X server that will
+  control multiple back-end X servers that make up the large display.
+
+
+  The overall structure of the distributed multihead X (DMX) project is
+  as follows: A single front-end X server will act as a proxy to a set
+  of back-end X servers, which handle all of the visible rendering.  X
+  clients will connect to the front-end server just as they normally
+  would to a regular X server.  The front-end server will present an
+  abstracted view to the client of a single large display.  This will
+  ensure that all standard X clients will continue to operate without
+  modification (limited, as always, by the visuals and extensions
+  provided by the X server).  Clients that are DMX-aware will be able to
+  use an extension to obtain information about the back-end servers
+  (e.g., for placement of pop-up windows, window alignments by the
+  window manager, etc.).
+
+
+  The architecture of the DMX server is divided into two main sections:
+  input (e.g., mouse and keyboard events) and output (e.g., rendering
+  and windowing requests).  Each of these are describe briefly below,
+  and the rest of this design document will describe them in greater
+  detail.
+
+
+  The DMX server can receive input from three general types of input
+  devices: "local" devices that are physically attached to the machine
+  on which DMX is running, "backend" devices that are physically
+  attached to one or more of the back-end X servers (and that generate
+  events via the X protocol stream from the backend), and "console"
+  devices that can be abstracted from any non-back-end X server.
+  Backend and console devices are treated differently because the
+  pointer device on the back-end X server also controls the location of
+  the hardware X cursor.  Full support for XInput extension devices is
+  provided.
+
+
+  Rendering requests will be accepted by the front-end server; however,
+  rendering to visible windows will be broken down as needed and sent to
+  the appropriate back-end server(s) via X11 library calls for actual
+  rendering.  The basic framework will follow a Xnest-style approach.
+  GC state will be managed in the front-end server and sent to the
+  appropriate back-end server(s) as required.  Pixmap rendering will (at
+  least initially) be handled by the front-end X server.  Windowing
+  requests (e.g., ordering, mapping, moving, etc.) will handled in the
+  front-end server.  If the request requires a visible change, the
+  windowing operation will be translated into requests for the
+  appropriate back-end server(s).  Window state will be mirrored in the
+  back-end server(s) as needed.
+
+
+  11..22..  LLaayyoouutt ooff PPaappeerr
+
+  The next section describes the general development plan that was
+  actually used for implementation.  The final section discusses
+  outstanding issues at the conclusion of development.  The first
+  appendix provides low-level technical detail that may be of interest
+  to those intimately familiar with the X server architecture.  The
+  final appendix describes the four phases of development that were
+  performed during the first two years of development.
+
+
+  The final year of work was divided into 9 tasks that are not described
+  in specific sections of this document.  The major tasks during that
+  time were the enhancement of the reconfiguration ability added in
+  Phase IV, addition of support for a dynamic number of back-end
+  displays (instead of a hard-coded limit), and the support for back-end
+  display and input removal and addition.  This work is mentioned in
+  this paper, but is not covered in detail.
+
+
+  22..  DDeevveellooppmmeenntt ppllaann
+
+  This section describes the development plan from approximately June
+  2001 through July 2003.
+
+
+
+  22..11..  BBoooottssttrraapp ccooddee
+
+  To allow for rapid development of the DMX server by multiple
+  developers during the first development stage, the problem will be
+  broken down into three tasks: the overall DMX framework, back-end
+  rendering services and input device handling services.  However,
+  before the work begins on these tasks, a simple framework that each
+  developer could use was implemented to bootstrap the development
+  effort.  This framework renders to a single back-end server and
+  provides dummy input devices (i.e., the keyboard and mouse).  The
+  simple back-end rendering service was implemented using the shadow
+  framebuffer support currently available in the XFree86 environment.
+
+
+  Using this bootstrapping framework, each developer has been able to
+  work on each of the tasks listed above independently as follows: the
+  framework will be extended to handle arbitrary back-end server
+  configurations; the back-end rendering services will be transitioned
+  to the more efficient Xnest-style implementation; and, an input device
+  framework to handle various input devices via the input extension will
+  be developed.
+
+
+  Status: The boot strap code is complete.
+
+
+
+  22..22..  IInnppuutt ddeevviiccee hhaannddlliinngg
+
+  An X server (including the front-end X server) requires two core input
+  devices -- a keyboard and a pointer (mouse).  These core devices are
+  handled and required by the core X11 protocol.  Additional types of
+  input devices may be attached and utilized via the XInput extension.
+  These are usually referred to as ``XInput extension devices'',
+
+
+  There are some options as to how the front-end X server gets its core
+  input devices:
+
+
+  1. Local Input. The physical input devices (e.g., keyboard and mouse)
+     can be attached directly to the front-end X server.  In this case,
+     the keyboard and mouse on the machine running the front-end X
+     server will be used.  The front-end will have drivers to read the
+     raw input from those devices and convert it into the required X
+     input events (e.g., key press/release, pointer button
+     press/release, pointer motion).  The front-end keyboard driver will
+     keep track of keyboard properties such as key and modifier
+     mappings, autorepeat state, keyboard sound and led state.
+     Similarly the front-end pointer driver will keep track if pointer
+     properties such as the button mapping and movement acceleration
+     parameters.  With this option, input is handled fully in the front-
+     end X server, and the back-end X servers are used in a display-only
+     mode.  This option was implemented and works for a limited number
+     of Linux-specific devices.  Adding additional local input devices
+     for other architectures is expected to be relatively simple.
+
+
+     The following options are available for implementing local input
+     devices:
+
+
+     a. The XFree86 X server has modular input drivers that could be
+        adapted for this purpose.  The mouse driver supports a wide
+        range of mouse types and interfaces, as well as a range of
+        Operating System platforms.  The keyboard driver in XFree86 is
+        not currently as modular as the mouse driver, but could be made
+        so.  The XFree86 X server also has a range of other input
+        drivers for extended input devices such as tablets and touch
+        screens.  Unfortunately, the XFree86 drivers are generally
+        complex, often simultaneously providing support for multiple
+        devices across multiple architectures; and rely so heavily on
+        XFree86-specific helper-functions, that this option was not
+        pursued.
+
+
+     b. The kdrive X server in XFree86 has built-in drivers that support
+        PS/2 mice and keyboard under Linux.  The mouse driver can
+        indirectly handle other mouse types if the Linux utility gpm is
+        used as to translate the native mouse protocol into PS/2 mouse
+        format.  These drivers could be adapted and built in to the
+        front-end X server if this range of hardware and OS support is
+        sufficient.  While much simpler than the XFree86 drivers, the
+        kdrive drivers were not used for the DMX implementation.
+
+     c. Reimplementation of keyboard and mouse drivers from scratch for
+        the DMX framework.  Because keyboard and mouse drivers are
+        relatively trivial to implement, this pathway was selected.
+        Other drivers in the X source tree were referenced, and
+        significant contributions from other drivers are noted in the
+        DMX source code.
+
+
+  2. Backend Input.  The front-end can make use of the core input
+     devices attached to one or more of the back-end X servers.  Core
+     input events from multiple back-ends are merged into a single input
+     event stream.  This can work sanely when only a single set of input
+     devices is used at any given time.  The keyboard and pointer state
+     will be handled in the front-end, with changes propagated to the
+     back-end servers as needed.  This option was implemented and works
+     well.  Because the core pointer on a back-end controls the hardware
+     mouse on that back-end, core pointers cannot be treated as XInput
+     extension devices.  However, all back-end XInput extensions devices
+     can be mapped to either DMX core or DMX XInput extension devices.
+
+  3. Console Input.  The front-end server could create a console window
+     that is displayed on an X server independent of the back-end X
+     servers.  This console window could display things like the
+     physical screen layout, and the front-end could get its core input
+     events from events delivered to the console window.  This option
+     was implemented and works well.  To help the human navigate, window
+     outlines are also displayed in the console window.  Further,
+     console windows can be used as either core or XInput extension
+     devices.
+
+  4. Other options were initially explored, but they were all partial
+     subsets of the options listed above and, hence, are irrelevant.
+
+
+  Although extended input devices are not specifically mentioned in the
+  Distributed X requirements, the options above were all implemented so
+  that XInput extension devices were supported.
+
+
+  The bootstrap code (Xdmx) had dummy input devices, and these are still
+  supported in the final version.  These do the necessary initialization
+  to satisfy the X server's requirements for core pointer and keyboard
+  devices, but no input events are ever generated.
+
+
+  Status: The input code is complete.  Because of the complexity of the
+  XFree86 input device drivers (and their heavy reliance on XFree86
+  infrastructure), separate low-level device drivers were implemented
+  for Xdmx.  The following kinds of drivers are supported (in general,
+  the devices can be treated arbitrarily as "core" input devices or as
+  XInput "extension" devices; and multiple instances of different kinds
+  of devices can be simultaneously available):
+
+  1. A "dummy" device drive that never generates events.
+
+  2. "Local" input is from the low-level hardware on which the Xdmx
+     binary is running.  This is the only area where using the XFree86
+     driver infrastructure would have been helpful, and then only
+     partially, since good support for generic USB devices does not yet
+     exist in XFree86 (in any case, XFree86 and kdrive driver code was
+     used where possible).  Currently, the following local devices are
+     supported under Linux (porting to other operating systems should be
+     fairly straightforward):
+
+     +o  Linux keyboard
+
+     +o  Linux serial mouse (MS)
+
+     +o  Linux PS/2 mouse
+
+     +o  USB keyboard
+
+     +o  USB mouse
+
+     +o  USB generic device (e.g., joystick, gamepad, etc.)
+
+
+  3. "Backend" input is taken from one or more of the back-end displays.
+     In this case, events are taken from the back-end X server and are
+     converted to Xdmx events.  Care must be taken so that the sprite
+     moves properly on the display from which input is being taken.
+
+  4. "Console" input is taken from an X window that Xdmx creates on the
+     operator's display (i.e., on the machine running the Xdmx binary).
+     When the operator's mouse is inside the console window, then those
+     events are converted to Xdmx events.  Several special features are
+     available: the console can display outlines of windows that are on
+     the Xdmx display (to facilitate navigation), the cursor can be
+     confined to the console, and a "fine" mode can be activated to
+     allow very precise cursor positioning.
+
+
+
+  22..33..  OOuuttppuutt ddeevviiccee hhaannddlliinngg
+
+  The output of the DMX system displays rendering and windowing requests
+  across multiple screens.  The screens are typically arranged in a grid
+  such that together they represent a single large display.
+
+
+  The output section of the DMX code consists of two parts.  The first
+  is in the front-end proxy X server (Xdmx), which accepts client
+  connections, manages the windows, and potentially renders primitives
+  but does not actually display any of the drawing primitives.  The
+  second part is the back-end X server(s), which accept commands from
+  the front-end server and display the results on their screens.
+
+
+  22..33..11..  IInniittiiaalliizzaattiioonn
+
+  The DMX front-end must first initialize its screens by connecting to
+  each of the back-end X servers and collecting information about each
+  of these screens.  However, the information collected from the back-
+  end X servers might be inconsistent.  Handling these cases can be
+  difficult and/or inefficient.  For example, a two screen system has
+  one back-end X server running at 16bpp while the second is running at
+  32bpp.  Converting rendering requests (e.g., XPutImage() or
+  XGetImage() requests) to the appropriate bit depth can be very time
+  consuming.  Analyzing these cases to determine how or even if it is
+  possible to handle them is required.  The current Xinerama code
+  handles many of these cases (e.g., in PanoramiXConsolidate()) and will
+  be used as a starting point.  In general, the best solution is to use
+  homogeneous X servers and display devices.  Using back-end servers
+  with the same depth is a requirement of the final DMX implementation.
+
+
+  Once this screen consolidation is finished, the relative position of
+  each back-end X server's screen in the unified screen is initialized.
+  A full-screen window is opened on each of the back-end X servers, and
+  the cursor on each screen is turned off.  The final DMX implementation
+  can also make use of a partial-screen window, or multiple windows per
+  back-end screen.
+
+
+  22..33..22..  HHaannddlliinngg rreennddeerriinngg rreeqquueessttss
+
+  After initialization, X applications connect to the front-end server.
+  There are two possible implementations of how rendering and windowing
+  requests are handled in the DMX system:
+
+
+  1. A shadow framebuffer is used in the front-end server as the render
+     target.  In this option, all protocol requests are completely
+     handled in the front-end server.  All state and resources are
+     maintained in the front-end including a shadow copy of the entire
+     framebuffer.  The framebuffers attached to the back-end servers are
+     updated by XPutImage() calls with data taken directly from the
+     shadow framebuffer.
+
+
+     This solution suffers from two main problems.  First, it does not
+     take advantage of any accelerated hardware available in the system.
+     Second, the size of the XPutImage() calls can be quite large and
+     thus will be limited by the bandwidth available.
+
+
+     The initial DMX implementation used a shadow framebuffer by
+     default.
+
+
+  2. Rendering requests are sent to each back-end server for handling
+     (as is done in the Xnest server described above).  In this option,
+     certain protocol requests are handled in the front-end server and
+     certain requests are repackaged and then sent to the back-end
+     servers.  The framebuffer is distributed across the multiple back-
+     end servers.  Rendering to the framebuffer is handled on each back-
+     end and can take advantage of any acceleration available on the
+     back-end servers' graphics display device.  State is maintained
+     both in the front and back-end servers.
+
+
+     This solution suffers from two main drawbacks.  First, protocol
+     requests are sent to all back-end servers -- even those that will
+     completely clip the rendering primitive -- which wastes bandwidth
+     and processing time.  Second, state is maintained both in the
+     front- and back-end servers.  These drawbacks are not as severe as
+     in option 1 (above) and can either be overcome through
+     optimizations or are acceptable.  Therefore, this option will be
+     used in the final implementation.
+
+
+     The final DMX implementation defaults to this mechanism, but also
+     supports the shadow framebuffer mechanism.  Several optimizations
+     were implemented to eliminate the drawbacks of the default
+     mechanism.  These optimizations are described the section below and
+     in Phase II of the Development Results (see appendix).
+
+
+
+  Status: Both the shadow framebuffer and Xnest-style code is complete.
+
+
+
+  22..44..  OOppttiimmiizziinngg DDMMXX
+
+  Initially, the Xnest-style solution's performance will be measured and
+  analyzed to determine where the performance bottlenecks exist.  There
+  are four main areas that will be addressed.
+
+
+  First, to obtain reasonable interactivity with the first development
+  phase, XSync() was called after each protocol request.  The XSync()
+  function flushes any pending protocol requests.  It then waits for the
+  back-end to process the request and send a reply that the request has
+  completed.  This happens with each back-end server and performance
+  greatly suffers.  As a result of the way XSync() is called in the
+  first development phase, the batching that the X11 library performs is
+  effectively defeated.  The XSync() call usage will be analyzed and
+  optimized by batching calls and performing them at regular intervals,
+  except where interactivity will suffer (e.g., on cursor movements).
+
+
+  Second, the initial Xnest-style solution described above sends the
+  repackaged protocol requests to all back-end servers regardless of
+  whether or not they would be completely clipped out.  The requests
+  that are trivially rejected on the back-end server wastes the limited
+  bandwidth available.  By tracking clipping changes in the DMX X
+  server's windowing code (e.g., by opening, closing, moving or resizing
+  windows), we can determine whether or not back-end windows are visible
+  so that trivial tests in the front-end server's GC ops drawing
+  functions can eliminate these unnecessary protocol requests.
+
+
+  Third, each protocol request will be analyzed to determine if it is
+  possible to break the request into smaller pieces at display
+  boundaries.  The initial ones to be analyzed are put and get image
+  requests since they will require the greatest bandwidth to transmit
+  data between the front and back-end servers.  Other protocol requests
+  will be analyzed and those that will benefit from breaking them into
+  smaller requests will be implemented.
+
+
+  Fourth, an extension is being considered that will allow font glyphs
+  to be transferred from the front-end DMX X server to each back-end
+  server.  This extension will permit the front-end to handle all font
+  requests and eliminate the requirement that all back-end X servers
+  share the exact same fonts as the front-end server.  We are
+  investigating the feasibility of this extension during this
+  development phase.
+
+
+  Other potential optimizations will be determined from the performance
+  analysis.
+
+  Please note that in our initial design, we proposed optimizing BLT
+  operations (e.g., XCopyArea() and window moves) by developing an
+  extension that would allow individual back-end servers to directly
+  copy pixel data to other back-end servers.  This potential
+  optimization was in response to the simple image movement
+  implementation that required potentially many calls to GetImage() and
+  PutImage().  However, the current Xinerama implementation handles
+  these BLT operations differently.  Instead of copying data to and from
+  screens, they generate expose events -- just as happens in the case
+  when a window is moved from off a screen to on screen.  This approach
+  saves the limited bandwidth available between front and back-end
+  servers and is being standardized with Xinerama.  It also eliminates
+  the potential setup problems and security issues resulting from having
+  each back-end server open connections to all other back-end servers.
+  Therefore, we suggest accepting Xinerama's expose event solution.
+
+
+  Also note that the approach proposed in the second and third
+  optimizations might cause backing store algorithms in the back-end to
+  be defeated, so a DMX X server configuration flag will be added to
+  disable these optimizations.
+
+
+  Status: The optimizations proposed above are complete.  It was
+  determined that the using the xfs font server was sufficient and
+  creating a new mechanism to pass glyphs was redundant; therefore, the
+  fourth optimization proposed above was not included in DMX.
+
+
+
+  22..55..  DDMMXX XX eexxtteennssiioonn ssuuppppoorrtt
+
+  The DMX X server keeps track of all the windowing information on the
+  back-end X servers, but does not currently export this information to
+  any client applications.  An extension will be developed to pass the
+  screen information and back-end window IDs to DMX-aware clients.
+  These clients can then use this information to directly connect to and
+  render to the back-end windows.  Bypassing the DMX X server allows
+  DMX-aware clients to break up complex rendering requests on their own
+  and send them directly to the windows on the back-end server's
+  screens.  An example of a client that can make effective use of this
+  extension is Chromium.
+
+
+  Status: The extension, as implemented, is fully documented in "Client-
+  to-Server DMX Extension to the X Protocol".  Future changes might be
+  required based on feedback and other proposed enhancements to DMX.
+  Currently, the following facilities are supported:
+
+  1. Screen information (clipping rectangle for each screen relative to
+     the virtual screen)
+
+  2. Window information (window IDs and clipping information for each
+     back-end window that corresponds to each DMX window)
+
+  3. Input device information (mappings from DMX device IDs to back-end
+     device IDs)
+
+  4. Force window creation (so that a client can override the server-
+     side lazy window creation optimization)
+
+  5. Reconfiguration (so that a client can request that a screen
+     position be changed)
+
+  6. Addition and removal of back-end servers and back-end and console
+     inputs.
+  22..66..  CCoommmmoonn XX eexxtteennssiioonn ssuuppppoorrtt
+
+  The XInput, XKeyboard and Shape extensions are commonly used
+  extensions to the base X11 protocol.  XInput allows multiple and non-
+  standard input devices to be accessed simultaneously.  These input
+  devices can be connected to either the front-end or back-end servers.
+  XKeyboard allows much better keyboard mappings control.  Shape adds
+  support for arbitrarily shaped windows and is used by various window
+  managers.  Nearly all potential back-end X servers make these
+  extensions available, and support for each one will be added to the
+  DMX system.
+
+
+  In addition to the extensions listed above, support for the X
+  Rendering extension (Render) is being developed.  Render adds digital
+  image composition to the rendering model used by the X Window System.
+  While this extension is still under development by Keith Packard of
+  HP, support for the current version will be added to the DMX system.
+
+
+  Support for the XTest extension was added during the first development
+  phase.
+
+
+  Status: The following extensions are supported and are discussed in
+  more detail in Phase IV of the Development Results (see appendix):
+  BIG-REQUESTS, DEC-XTRAP, DMX, DPMS, Extended-Visual-Information, GLX,
+  LBX, RECORD, RENDER, SECURITY, SHAPE, SYNC, X-Resource, XC-APPGROUP,
+  XC-MISC, XFree86-Bigfont, XINERAMA, XInputExtension, XKEYBOARD, and
+  XTEST.
+
+
+  22..77..  OOppeennGGLL ssuuppppoorrtt
+
+  OpenGL support using the Mesa code base exists in XFree86 release 4
+  and later.  Currently, the direct rendering infrastructure (DRI)
+  provides accelerated OpenGL support for local clients and
+  unaccelerated OpenGL support (i.e., software rendering) is provided
+  for non-local clients.
+
+
+  The single head OpenGL support in XFree86 4.x will be extended to use
+  the DMX system.  When the front and back-end servers are on the same
+  physical hardware, it is possible to use the DRI to directly render to
+  the back-end servers.  First, the existing DRI will be extended to
+  support multiple display heads, and then to support the DMX system.
+  OpenGL rendering requests will be direct rendering to each back-end X
+  server.  The DRI will request the screen layout (either from the
+  existing Xinerama extension or a DMX-specific extension).  Support for
+  synchronized swap buffers will also be added (on hardware that
+  supports it).  Note that a single front-end server with a single back-
+  end server on the same physical machine can emulate accelerated
+  indirect rendering.
+
+
+  When the front and back-end servers are on different physical hardware
+  or are using non-XFree86 4.x X servers, a mechanism to render
+  primitives across the back-end servers will be provided.  There are
+  several options as to how this can be implemented.
+
+
+  1. The existing OpenGL support in each back-end server can be used by
+     repackaging rendering primitives and sending them to each back-end
+     server.  This option is similar to the unoptimized Xnest-style
+     approach mentioned above.  Optimization of this solution is beyond
+     the scope of this project and is better suited to other distributed
+     rendering systems.
+
+  2. Rendering to a pixmap in the front-end server using the current
+     XFree86 4.x code, and then displaying to the back-ends via calls to
+     XPutImage() is another option.  This option is similar to the
+     shadow frame buffer approach mentioned above.  It is slower and
+     bandwidth intensive, but has the advantage that the back-end
+     servers are not required to have OpenGL support.
+
+
+  These, and other, options will be investigated in this phase of the
+  work.
+
+
+  Work by others have made Chromium DMX-aware.  Chromium will use the
+  DMX X protocol extension to obtain information about the back-end
+  servers and will render directly to those servers, bypassing DMX.
+
+
+  Status: OpenGL support by the glxProxy extension was implemented by
+  SGI and has been integrated into the DMX code base.
+
+
+
+  33..  CCuurrrreenntt iissssuueess
+
+  In this sections the current issues are outlined that require further
+  investigation.
+
+
+  33..11..  FFoonnttss
+
+  The font path and glyphs need to be the same for the front-end and
+  each of the back-end servers.  Font glyphs could be sent to the back-
+  end servers as necessary but this would consume a significant amount
+  of available bandwidth during font rendering for clients that use many
+  different fonts (e.g., Netscape).  Initially, the font server (xfs)
+  will be used to provide the fonts to both the front-end and back-end
+  servers.  Other possibilities will be investigated during development.
+
+
+  33..22..  ZZeerroo wwiiddtthh rreennddeerriinngg pprriimmiittiivveess
+
+  To allow pixmap and on-screen rendering to be pixel perfect, all back-
+  end servers must render zero width primitives exactly the same as the
+  front-end renders the primitives to pixmaps.  For those back-end
+  servers that do not exactly match, zero width primitives will be
+  automatically converted to one width primitives.  This can be handled
+  in the front-end server via the GC state.
+
+
+  33..33..  OOuuttppuutt ssccaalliinngg
+
+  With very large tiled displays, it might be difficult to read the
+  information on the standard X desktop.  In particular, the cursor can
+  be easily lost and fonts could be difficult to read.  Automatic
+  primitive scaling might prove to be very useful.  We will investigate
+  the possibility of scaling the cursor and providing a set of alternate
+  pre-scaled fonts to replace the standard fonts that many applications
+  use (e.g., fixed).  Other options for automatic scaling will also be
+  investigated.
+
+
+
+  33..44..  PPeerr--ssccrreeeenn ccoolloorrmmaappss
+
+  Each screen's default colormap in the set of back-end X servers should
+  be able to be adjusted via a configuration utility.  This support is
+  would allow the back-end screens to be calibrated via custom gamma
+  tables.  On 24-bit systems that support a DirectColor visual, this
+  type of correction can be accommodated.  One possible implementation
+  would be to advertise to X client of the DMX server a TrueColor visual
+  while using DirectColor visuals on the back-end servers to implement
+  this type of color correction.  Other options will be investigated.
+
+
+  AA..  BBaacckkggrroouunndd
+
+  This section describes the existing Open Source architectures that can
+  be used to handle multiple screens and upon which this development
+  project is based.  This section was written before the implementation
+  was finished, and may not reflect actual details of the
+  implementation.  It is left for historical interest only.
+
+
+  AA..11..  CCoorree iinnppuutt ddeevviiccee hhaannddlliinngg
+
+  The following is a description of how core input devices are handled
+  by an X server.
+
+
+  AA..11..11..  IInniittIInnppuutt(())
+
+  InitInput() is a DDX function that is called at the start of each
+  server generation from the X server's main() function.  Its purpose is
+  to determine what input devices are connected to the X server,
+  register them with the DIX and MI layers, and initialize the input
+  event queue.  InitInput() does not have a return value, but the X
+  server will abort if either a core keyboard device or a core pointer
+  device are not registered.  Extended input (XInput) devices can also
+  be registered in InitInput().
+
+
+  InitInput() usually has implementation specific code to determine
+  which input devices are available.  For each input device it will be
+  using, it calls AddInputDevice():
+
+
+     AAddddIInnppuuttDDeevviiccee(())
+        This DIX function allocates the device structure, registers a
+        callback function (which handles device init, close, on and
+        off), and returns the input handle, which can be treated as
+        opaque.  It is called once for each input device.
+
+
+  Once input handles for core keyboard and core pointer devices have
+  been obtained from AddInputDevice(), they are registered as core
+  devices by calling RegisterPointerDevice() and
+  RegisterKeyboardDevice().  Each of these should be called once.  If
+  both core devices are not registered, then the X server will exit with
+  a fatal error when it attempts to start the input devices in
+  InitAndStartDevices(), which is called directly after InitInput() (see
+  below).
+
+
+     RReeggiisstteerr{{PPooiinntteerr,,KKeeyybbooaarrdd}}DDeevviiccee(())
+        These DIX functions take a handle returned from AddInputDevice()
+        and initialize the core input device fields in inputInfo, and
+        initialize the input processing and grab functions for each core
+        input device.
+  The core pointer device is then registered with the miPointer code
+  (which does the high level cursor handling).  While this registration
+  is not necessary for correct miPointer operation in the current
+  XFree86 code, it is still done mostly for compatibility reasons.
+
+
+     mmiiRReeggiisstteerrPPooiinntteerrDDeevviiccee(())
+        This MI function registers the core pointer's input handle with
+        with the miPointer code.
+
+
+  The final part of InitInput() is the initialization of the input event
+  queue handling.  In most cases, the event queue handling provided in
+  the MI layer is used.  The primary XFree86 X server uses its own event
+  queue handling to support some special cases related to the XInput
+  extension and the XFree86-specific DGA extension.  For our purposes,
+  the MI event queue handling should be suitable.  It is initialized by
+  calling mieqInit():
+
+
+     mmiieeqqIInniitt(())
+        This MI function initializes the MI event queue for the core
+        devices, and is passed the public component of the input handles
+        for the two core devices.
+
+
+  If a wakeup handler is required to deliver synchronous input events,
+  it can be registered here by calling the DIX function
+  RegisterBlockAndWakeupHandlers().  (See the devReadInput() description
+  below.)
+
+
+  AA..11..22..  IInniittAAnnddSSttaarrttDDeevviicceess(())
+
+  InitAndStartDevices() is a DIX function that is called immediately
+  after InitInput() from the X server's main() function.  Its purpose is
+  to initialize each input device that was registered with
+  AddInputDevice(), enable each input device that was successfully
+  initialized, and create the list of enabled input devices.  Once each
+  registered device is processed in this way, the list of enabled input
+  devices is checked to make sure that both a core keyboard device and
+  core pointer device were registered and successfully enabled.  If not,
+  InitAndStartDevices() returns failure, and results in the the X server
+  exiting with a fatal error.
+
+
+  Each registered device is initialized by calling its callback
+  (dev->deviceProc) with the DEVICE_INIT argument:
+
+
+     ((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__IINNIITT))
+        This function initializes the device structs with core
+        information relevant to the device.
+
+
+        For pointer devices, this means specifying the number of
+        buttons, default button mapping, the function used to get motion
+        events (usually miPointerGetMotionEvents()), the function used
+        to change/control the core pointer motion parameters
+        (acceleration and threshold), and the motion buffer size.
+
+
+        For keyboard devices, this means specifying the keycode range,
+        default keycode to keysym mapping, default modifier mapping, and
+        the functions used to sound the keyboard bell and modify/control
+        the keyboard parameters (LEDs, bell pitch and duration, key
+        click, which keys are auto-repeating, etc).
+
+
+  Each initialized device is enabled by calling EnableDevice():
+
+
+     EEnnaabblleeDDeevviiccee(())
+        EnableDevice() calls the device callback with DEVICE_ON:
+
+        ((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__OONN))
+           This typically opens and initializes the relevant physical
+           device, and when appropriate, registers the device's file
+           descriptor (or equivalent) as a valid input source.
+
+
+        EnableDevice() then adds the device handle to the X server's
+        global list of enabled devices.
+
+
+  InitAndStartDevices() then verifies that a valid core keyboard and
+  pointer has been initialized and enabled.  It returns failure if
+  either are missing.
+
+
+  AA..11..33..  ddeevvRReeaaddIInnppuutt(())
+
+  Each device will have some function that gets called to read its
+  physical input.  These may be called in a number of different ways.
+  In the case of synchronous I/O, they will be called from a DDX wakeup-
+  handler that gets called after the server detects that new input is
+  available.  In the case of asynchronous I/O, they will be called from
+  a (SIGIO) signal handler triggered when new input is available.  This
+  function should do at least two things: make sure that input events
+  get enqueued, and make sure that the cursor gets moved for motion
+  events (except if these are handled later by the driver's own event
+  queue processing function, which cannot be done when using the MI
+  event queue handling).
+
+
+  Events are queued by calling mieqEnqueue():
+
+
+     mmiieeqqEEnnqquueeuuee(())
+        This MI function is used to add input events to the event queue.
+        It is simply passed the event to be queued.
+
+
+  The cursor position should be updated when motion events are enqueued,
+  by calling either miPointerAbsoluteCursor() or miPointerDeltaCursor():
+
+
+     mmiiPPooiinntteerrAAbbssoolluutteeCCuurrssoorr(())
+        This MI function is used to move the cursor to the absolute
+        coordinates provided.
+
+     mmiiPPooiinntteerrDDeellttaaCCuurrssoorr(())
+        This MI function is used to move the cursor relative to its
+        current position.
+
+
+  AA..11..44..  PPrroocceessssIInnppuuttEEvveennttss(())
+
+  ProcessInputEvents() is a DDX function that is called from the X
+  server's main dispatch loop when new events are available in the input
+  event queue.  It typically processes the enqueued events, and updates
+  the cursor/pointer position.  It may also do other DDX-specific event
+  processing.
+
+
+  Enqueued events are processed by mieqProcessInputEvents() and passed
+  to the DIX layer for transmission to clients:
+
+
+     mmiieeqqPPrroocceessssIInnppuuttEEvveennttss(())
+        This function processes each event in the event queue, and
+        passes it to the device's input processing function.  The DIX
+        layer provides default functions to do this processing, and they
+        handle the task of getting the events passed back to the
+        relevant clients.
+
+     mmiiPPooiinntteerrUUppddaattee(())
+        This function resynchronized the cursor position with the new
+        pointer position.  It also takes care of moving the cursor
+        between screens when needed in multi-head configurations.
+
+
+
+  AA..11..55..  DDiissaabblleeDDeevviiccee(())
+
+  DisableDevice is a DIX function that removes an input device from the
+  list of enabled devices.  The result of this is that the device no
+  longer generates input events.  The device's data structures are kept
+  in place, and disabling a device like this can be reversed by calling
+  EnableDevice().  DisableDevice() may be called from the DDX when it is
+  desirable to do so (e.g., the XFree86 server does this when VT
+  switching).  Except for special cases, this is not normally called for
+  core input devices.
+
+
+  DisableDevice() calls the device's callback function with DEVICE_OFF:
+
+
+     ((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__OOFFFF))
+        This typically closes the relevant physical device, and when
+        appropriate, unregisters the device's file descriptor (or
+        equivalent) as a valid input source.
+
+
+  DisableDevice() then removes the device handle from the X server's
+  global list of enabled devices.
+
+
+
+  AA..11..66..  CClloosseeDDeevviiccee(())
+
+  CloseDevice is a DIX function that removes an input device from the
+  list of available devices.  It disables input from the device and
+  frees all data structures associated with the device.  This function
+  is usually called from CloseDownDevices(), which is called from main()
+  at the end of each server generation to close all input devices.
+
+
+  CloseDevice() calls the device's callback function with DEVICE_CLOSE:
+
+
+     ((**ddeevv-->>ddeevviicceePPrroocc))((ddeevv,, DDEEVVIICCEE__CCLLOOSSEE))
+        This typically closes the relevant physical device, and when
+        appropriate, unregisters the device's file descriptor (or
+        equivalent) as a valid input source.  If any device specific
+        data structures were allocated when the device was initialized,
+        they are freed here.
+
+  CloseDevice() then frees the data structures that were allocated for
+  the device when it was registered/initialized.
+
+
+
+  AA..11..77..  LLeeggaallMMooddiiffiieerr(())
+
+  LegalModifier() is a required DDX function that can be used to
+  restrict which keys may be modifier keys.  This seems to be present
+  for historical reasons, so this function should simply return TRUE
+  unconditionally.
+
+
+
+  AA..22..  OOuuttppuutt hhaannddlliinngg
+
+  The following sections describe the main functions required to
+  initialize, use and close the output device(s) for each screen in the
+  X server.
+
+
+  AA..22..11..  IInniittOOuuttppuutt(())
+
+  This DDX function is called near the start of each server generation
+  from the X server's main() function.  InitOutput()'s main purpose is
+  to initialize each screen and fill in the global screenInfo structure
+  for each screen.  It is passed three arguments: a pointer to the
+  screenInfo struct, which it is to initialize, and argc and argv from
+  main(), which can be used to determine additional configuration
+  information.
+
+
+  The primary tasks for this function are outlined below:
+
+
+  1. PPaarrssee ccoonnffiigguurraattiioonn iinnffoo:: The first task of InitOutput() is to
+     parses any configuration information from the configuration file.
+     In addition to the XF86Config file, other configuration information
+     can be taken from the command line.  The command line options can
+     be gathered either in InitOutput() or earlier in the
+     ddxProcessArgument() function, which is called by
+     ProcessCommandLine().  The configuration information determines the
+     characteristics of the screen(s).  For example, in the XFree86 X
+     server, the XF86Config file specifies the monitor information, the
+     screen resolution, the graphics devices and slots in which they are
+     located, and, for Xinerama, the screens' layout.
+
+  2. IInniittiiaalliizzee ssccrreeeenn iinnffoo:: The next task is to initialize the screen-
+     dependent internal data structures.  For example, part of what the
+     XFree86 X server does is to allocate its screen and pixmap private
+     indices, probe for graphics devices, compare the probed devices to
+     the ones listed in the XF86Config file, and add the ones that match
+     to the internal xf86Screens[] structure.
+
+  3. SSeett ppiixxmmaapp ffoorrmmaattss:: The next task is to initialize the screenInfo's
+     image byte order, bitmap bit order and bitmap scanline unit/pad.
+     The screenInfo's pixmap format's depth, bits per pixel and scanline
+     padding is also initialized at this stage.
+
+  4. UUnniiffyy ssccrreeeenn iinnffoo:: An optional task that might be done at this
+     stage is to compare all of the information from the various screens
+     and determines if they are compatible (i.e., if the set of screens
+     can be unified into a single desktop).  This task has potential to
+     be useful to the DMX front-end server, if Xinerama's
+     PanoramiXConsolidate() function is not sufficient.
+
+  Once these tasks are complete, the valid screens are known and each of
+  these screens can be initialized by calling AddScreen().
+
+
+  AA..22..22..  AAddddSSccrreeeenn(())
+
+  This DIX function is called from InitOutput(), in the DDX layer, to
+  add each new screen to the screenInfo structure.  The DDX screen
+  initialization function and command line arguments (i.e., argc and
+  argv) are passed to it as arguments.
+
+
+  This function first allocates a new Screen structure and any privates
+  that are required.  It then initializes some of the fields in the
+  Screen struct and sets up the pixmap padding information.  Finally, it
+  calls the DDX screen initialization function ScreenInit(), which is
+  described below.  It returns the number of the screen that were just
+  added, or -1 if there is insufficient memory to add the screen or if
+  the DDX screen initialization fails.
+
+
+  AA..22..33..  SSccrreeeennIInniitt(())
+
+  This DDX function initializes the rest of the Screen structure with
+  either generic or screen-specific functions (as necessary).  It also
+  fills in various screen attributes (e.g., width and height in
+  millimeters, black and white pixel values).
+
+
+  The screen init function usually calls several functions to perform
+  certain screen initialization functions.  They are described below:
+
+
+     {{mmii,,**ffbb}}SSccrreeeennIInniitt(())
+        The DDX layer's ScreenInit() function usually calls another
+        layer's ScreenInit() function (e.g., miScreenInit() or
+        fbScreenInit()) to initialize the fallbacks that the DDX driver
+        does not specifically handle.
+
+
+        After calling another layer's ScreenInit() function, any screen-
+        specific functions either wrap or replace the other layer's
+        function pointers.  If a function is to be wrapped, each of the
+        old function pointers from the other layer are stored in a
+        screen private area.  Common functions to wrap are CloseScreen()
+        and SaveScreen().
+
+
+     mmiiIInniittiiaalliizzeeBBaacckkiinnggSSttoorree(())
+        This MI function initializes the screen's backing storage
+        functions, which are used to save areas of windows that are
+        currently covered by other windows.
+
+
+     mmiiDDCCIInniittiiaalliizzee(())
+        This MI function initializes the MI cursor display structures
+        and function pointers.  If a hardware cursor is used, the DDX
+        layer's ScreenInit() function will wrap additional screen and
+        the MI cursor display function pointers.
+
+
+  Another common task for ScreenInit() function is to initialize the
+  output device state.  For example, in the XFree86 X server, the
+  ScreenInit() function saves the original state of the video card and
+  then initializes the video mode of the graphics device.
+
+  AA..22..44..  CClloosseeSSccrreeeenn(())
+
+  This function restores any wrapped screen functions (and in particular
+  the wrapped CloseScreen() function) and restores the state of the
+  output device to its original state.  It should also free any private
+  data it created during the screen initialization.
+
+
+  AA..22..55..  GGCC ooppeerraattiioonnss
+
+  When the X server is requested to render drawing primitives, it does
+  so by calling drawing functions through the graphics context's
+  operation function pointer table (i.e., the GCOps functions).  These
+  functions render the basic graphics operations such as drawing
+  rectangles, lines, text or copying pixmaps.  Default routines are
+  provided either by the MI layer, which draws indirectly through a
+  simple span interface, or by the framebuffer layers (e.g., CFB, MFB,
+  FB), which draw directly to a linearly mapped frame buffer.
+
+
+  To take advantage of special hardware on the graphics device, specific
+  GCOps functions can be replaced by device specific code.  However,
+  many times the graphics devices can handle only a subset of the
+  possible states of the GC, so during graphics context validation,
+  appropriate routines are selected based on the state and capabilities
+  of the hardware.  For example, some graphics hardware can accelerate
+  single pixel width lines with certain dash patterns.  Thus, for dash
+  patterns that are not supported by hardware or for width 2 or greater
+  lines, the default routine is chosen during GC validation.
+
+
+  Note that some pointers to functions that draw to the screen are
+  stored in the Screen structure.  They include GetImage(), GetSpans(),
+  PaintWindowBackground(), PaintWindowBorder(), CopyWindow() and
+  RestoreAreas().
+
+
+  AA..22..66..  XXnneesstt
+
+  The Xnest X server is a special proxy X server that relays the X
+  protocol requests that it receives to a ``real'' X server that then
+  processes the requests and displays the results, if applicable.  To
+  the X applications, Xnest appears as if it is a regular X server.
+  However, Xnest is both server to the X application and client of the
+  real X server, which will actually handle the requests.
+
+
+  The Xnest server implements all of the standard input and output
+  initialization steps outlined above.
+
+
+     IInniittOOuuttppuutt(())
+        Xnest takes its configuration information from command line
+        arguments via ddxProcessArguments().  This information includes
+        the real X server display to connect to, its default visual
+        class, the screen depth, the Xnest window's geometry, etc.
+        Xnest then connects to the real X server and gathers visual,
+        colormap, depth and pixmap information about that server's
+        display, creates a window on that server, which will be used as
+        the root window for Xnest.
+
+
+        Next, Xnest initializes its internal data structures and uses
+        the data from the real X server's pixmaps to initialize its own
+        pixmap formats.  Finally, it calls AddScreen(xnestOpenScreen,
+        argc, argv) to initialize each of its screens.
+     SSccrreeeennIInniitt(())
+        Xnest's ScreenInit() function is called xnestOpenScreen().  This
+        function initializes its screen's depth and visual information,
+        and then calls miScreenInit() to set up the default screen
+        functions.  It then calls miInitializeBackingStore() and
+        miDCInitialize() to initialize backing store and the software
+        cursor.  Finally, it replaces many of the screen functions with
+        its own functions that repackage and send the requests to the
+        real X server to which Xnest is attached.
+
+
+     CClloosseeSSccrreeeenn(())
+        This function frees its internal data structure allocations.
+        Since it replaces instead of wrapping screen functions, there
+        are no function pointers to unwrap.  This can potentially lead
+        to problems during server regeneration.
+
+
+     GGCC ooppeerraattiioonnss
+        The GC operations in Xnest are very simple since they leave all
+        of the drawing to the real X server to which Xnest is attached.
+        Each of the GCOps takes the request and sends it to the real X
+        server using standard Xlib calls.  For example, the X
+        application issues a XDrawLines() call.  This function turns
+        into a protocol request to Xnest, which calls the
+        xnestPolylines() function through Xnest's GCOps function pointer
+        table.  The xnestPolylines() function is only a single line,
+        which calls XDrawLines() using the same arguments that were
+        passed into it.  Other GCOps functions are very similar.  Two
+        exceptions to the simple GCOps functions described above are the
+        image functions and the BLT operations.
+
+
+        The image functions, GetImage() and PutImage(), must use a
+        temporary image to hold the image to be put of the image that
+        was just grabbed from the screen while it is in transit to the
+        real X server or the client.  When the image has been
+        transmitted, the temporary image is destroyed.
+
+
+        The BLT operations, CopyArea() and CopyPlane(), handle not only
+        the copy function, which is the same as the simple cases
+        described above, but also the graphics exposures that result
+        when the GC's graphics exposure bit is set to True.  Graphics
+        exposures are handled in a helper function,
+        xnestBitBlitHelper().  This function collects the exposure
+        events from the real X server and, if any resulting in regions
+        being exposed, then those regions are passed back to the MI
+        layer so that it can generate exposure events for the X
+        application.
+
+
+  The Xnest server takes its input from the X server to which it is
+  connected.  When the mouse is in the Xnest server's window, keyboard
+  and mouse events are received by the Xnest server, repackaged and sent
+  back to any client that requests those events.
+
+
+  AA..22..77..  SShhaaddooww ffrraammeebbuuffffeerr
+
+  The most common type of framebuffer is a linear array memory that maps
+  to the video memory on the graphics device.  However, accessing that
+  video memory over an I/O bus (e.g., ISA or PCI) can be slow.  The
+  shadow framebuffer layer allows the developer to keep the entire
+  framebuffer in main memory and copy it back to video memory at regular
+  intervals.  It also has been extended to handle planar video memory
+  and rotated framebuffers.
+
+
+  There are two main entry points to the shadow framebuffer code:
+
+
+     sshhaaddoowwAAlllloocc((wwiiddtthh,, hheeiigghhtt,, bbpppp))
+        This function allocates the in memory copy of the framebuffer of
+        size width*height*bpp.  It returns a pointer to that memory,
+        which will be used by the framebuffer ScreenInit() code during
+        the screen's initialization.
+
+
+     sshhaaddoowwIInniitt((ppSSccrreeeenn,, uuppddaatteePPrroocc,, wwiinnddoowwPPrroocc))
+        This function initializes the shadow framebuffer layer.  It
+        wraps several screen drawing functions, and registers a block
+        handler that will update the screen.  The updateProc is a
+        function that will copy the damaged regions to the screen, and
+        the windowProc is a function that is used when the entire linear
+        video memory range cannot be accessed simultaneously so that
+        only a window into that memory is available (e.g., when using
+        the VGA aperture).
+
+
+  The shadow framebuffer code keeps track of the damaged area of each
+  screen by calculating the bounding box of all drawing operations that
+  have occurred since the last screen update.  Then, when the block
+  handler is next called, only the damaged portion of the screen is
+  updated.
+
+
+  Note that since the shadow framebuffer is kept in main memory, all
+  drawing operations are performed by the CPU and, thus, no accelerated
+  hardware drawing operations are possible.
+
+
+
+  AA..33..  XXiinneerraammaa
+
+  Xinerama is an X extension that allows multiple physical screens
+  controlled by a single X server to appear as a single screen.
+  Although the extension allows clients to find the physical screen
+  layout via extension requests, it is completely transparent to clients
+  at the core X11 protocol level.  The original public implementation of
+  Xinerama came from Digital/Compaq.  XFree86 rewrote it, filling in
+  some missing pieces and improving both X11 core protocol compliance
+  and performance.  The Xinerama extension will be passing through
+  X.Org's standardization process in the near future, and the sample
+  implementation will be based on this rewritten version.
+
+
+  The current implementation of Xinerama is based primarily in the DIX
+  (device independent) and MI (machine independent) layers of the X
+  server.  With few exceptions the DDX layers do not need any changes to
+  support Xinerama.  X server extensions often do need modifications to
+  provide full Xinerama functionality.
+
+
+  The following is a code-level description of how Xinerama functions.
+
+
+  Note: Because the Xinerama extension was originally called the
+  PanoramiX extension, many of the Xinerama functions still have the
+  PanoramiX prefix.
+
+
+     PPaannoorraammiiXXEExxtteennssiioonnIInniitt(())
+        PanoramiXExtensionInit() is a device-independent extension
+        function that is called at the start of each server generation
+        from InitExtensions(), which is called from the X server's
+        main() function after all output devices have been initialized,
+        but before any input devices have been initialized.
+
+
+        PanoramiXNumScreens is set to the number of physical screens.
+        If only one physical screen is present, the extension is
+        disabled, and PanoramiXExtensionInit() returns without doing
+        anything else.
+
+
+        The Xinerama extension is registered by calling AddExtension().
+
+
+        A local per-screen array of data structures (panoramiXdataPtr[])
+        is allocated for each physical screen, and GC and Screen private
+        indexes are allocated, and both GC and Screen private areas are
+        allocated for each physical screen.  These hold Xinerama-
+        specific per-GC and per-Screen data.  Each screen's CreateGC and
+        CloseScreen functions are wrapped by XineramaCreateGC() and
+        XineramaCloseScreen() respectively.  Some new resource classes
+        are created for Xinerama drawables and GCs, and resource types
+        for Xinerama windows, pixmaps and colormaps.
+
+
+        A region (XineramaScreenRegions[i]) is initialized for each
+        physical screen, and single region (PanoramiXScreenRegion) is
+        initialized to be the union of the screen regions.  The
+        panoramiXdataPtr[] array is also initialized with the size and
+        origin of each screen.  The relative positioning information for
+        the physical screens is taken from the array dixScreenOrigins[],
+        which the DDX layer must initialize in InitOutput().  The bounds
+        of the combined screen is also calculated (PanoramiXPixWidth and
+        PanoramiXPixHeight).
+
+
+        The DIX layer has a list of function pointers (ProcVector[])
+        that holds the entry points for the functions that process core
+        protocol requests.  The requests that Xinerama must intercept
+        and break up into physical screen-specific requests are wrapped.
+        The original set is copied to SavedProcVector[].  The types of
+        requests intercepted are Window requests, GC requests, colormap
+        requests, drawing requests, and some geometry-related requests.
+        This wrapping allows the bulk of the protocol request processing
+        to be handled transparently to the DIX layer.  Some operations
+        cannot be dealt with in this way and are handled with Xinerama-
+        specific code within the DIX layer.
+
+
+     PPaannoorraammiiXXCCoonnssoolliiddaattee(())
+        PanoramiXConsolidate() is a device-independent extension
+        function that is called directly from the X server's main()
+        function after extensions and input/output devices have been
+        initialized, and before the root windows are defined and
+        initialized.
+
+
+        This function finds the set of depths (PanoramiXDepths[]) and
+        visuals (PanoramiXVisuals[]) common to all of the physical
+        screens.  PanoramiXNumDepths is set to the number of common
+        depths, and PanoramiXNumVisuals is set to the number of common
+        visuals.  Resources are created for the single root window and
+        the default colormap.  Each of these resources has per-physical
+        screen entries.
+
+
+     PPaannoorraammiiXXCCrreeaatteeCCoonnnneeccttiioonnBBlloocckk(())
+        PanoramiXConsolidate() is a device-independent extension
+        function that is called directly from the X server's main()
+        function after the per-physical screen root windows are created.
+        It is called instead of the standard DIX CreateConnectionBlock()
+        function.  If this function returns FALSE, the X server exits
+        with a fatal error.  This function will return FALSE if no
+        common depths were found in PanoramiXConsolidate().  With no
+        common depths, Xinerama mode is not possible.
+
+
+        The connection block holds the information that clients get when
+        they open a connection to the X server.  It includes information
+        such as the supported pixmap formats, number of screens and the
+        sizes, depths, visuals, default colormap information, etc, for
+        each of the screens (much of information that xdpyinfo shows).
+        The connection block is initialized with the combined single
+        screen values that were calculated in the above two functions.
+
+
+        The Xinerama extension allows the registration of connection
+        block callback functions.  The purpose of these is to allow
+        other extensions to do processing at this point.  These
+        callbacks can be registered by calling
+        XineramaRegisterConnectionBlockCallback() from the other
+        extension's ExtensionInit() function.  Each registered
+        connection block callback is called at the end of
+        PanoramiXCreateConnectionBlock().
+
+
+  AA..33..11..  XXiinneerraammaa--ssppeecciiffiicc cchhaannggeess ttoo tthhee DDIIXX ccooddee
+
+  There are a few types of Xinerama-specific changes within the DIX
+  code.  The main ones are described here.
+
+
+  Functions that deal with colormap or GC -related operations outside of
+  the intercepted protocol requests have a test added to only do the
+  processing for screen numbers > 0.  This is because they are handled
+  for the single Xinerama screen and the processing is done once for
+  screen 0.
+
+
+  The handling of motion events does some coordinate translation between
+  the physical screen's origin and screen zero's origin.  Also, motion
+  events must be reported relative to the composite screen origin rather
+  than the physical screen origins.
+
+
+  There is some special handling for cursor, window and event processing
+  that cannot (either not at all or not conveniently) be done via the
+  intercepted protocol requests.  A particular case is the handling of
+  pointers moving between physical screens.
+
+
+  AA..33..22..  XXiinneerraammaa--ssppeecciiffiicc cchhaannggeess ttoo tthhee MMII ccooddee
+
+  The only Xinerama-specific change to the MI code is in
+  miSendExposures() to handle the coordinate (and window ID) translation
+  for expose events.
+
+
+
+  AA..33..33..  IInntteerrcceepptteedd DDIIXX ccoorree rreeqquueessttss
+
+  Xinerama breaks up drawing requests for dispatch to each physical
+  screen.  It also breaks up windows into pieces for each physical
+  screen.  GCs are translated into per-screen GCs.  Colormaps are
+  replicated on each physical screen.  The functions handling the
+  intercepted requests take care of breaking the requests and
+  repackaging them so that they can be passed to the standard request
+  handling functions for each screen in turn.  In addition, and to aid
+  the repackaging, the information from many of the intercepted requests
+  is used to keep up to date the necessary state information for the
+  single composite screen.  Requests (usually those with replies) that
+  can be satisfied completely from this stored state information do not
+  call the standard request handling functions.
+
+
+
+  BB..  DDeevveellooppmmeenntt RReessuullttss
+
+  In this section the results of each phase of development are
+  discussed.  This development took place between approximately June
+  2001 and July 2003.
+
+
+  BB..11..  PPhhaassee II
+
+  The initial development phase dealt with the basic implementation
+  including the bootstrap code, which used the shadow framebuffer, and
+  the unoptimized implementation, based on an Xnest-style
+  implementation.
+
+
+  BB..11..11..  SSccooppee
+
+  The goal of Phase I is to provide fundamental functionality that can
+  act as a foundation for ongoing work:
+
+  1. Develop the proxy X server
+
+     +o  The proxy X server will operate on the X11 protocol and relay
+        requests as necessary to correctly perform the request.
+
+     +o  Work will be based on the existing work for Xinerama and Xnest.
+
+     +o  Input events and windowing operations are handled in the proxy
+        server and rendering requests are repackaged and sent to each of
+        the back-end servers for display.
+
+     +o  The multiple screen layout (including support for overlapping
+        screens) will be user configurable via a configuration file or
+        through the configuration tool.
+
+  2. Develop graphical configuration tool
+
+     +o  There will be potentially a large number of X servers to
+        configure into a single display.  The tool will allow the user
+        to specify which servers are involved in the configuration and
+        how they should be laid out.
+
+  3. Pass the X Test Suite
+
+     +o  The X Test Suite covers the basic X11 operations.  All tests
+        known to succeed must correctly operate in the distributed X
+        environment.
+
+
+  For this phase, the back-end X servers are assumed to be unmodified X
+  servers that do not support any DMX-related protocol extensions;
+  future optimization pathways are considered, but are not implemented;
+  and the configuration tool is assumed to rely only on libraries in the
+  X source tree (e.g., Xt).
+
+
+  BB..11..22..  RReessuullttss
+
+  The proxy X server, Xdmx, was developed to distribute X11 protocol
+  requests to the set of back-end X servers.  It opens a window on each
+  back-end server, which represents the part of the front-end's root
+  window that is visible on that screen.  It mirrors window, pixmap and
+  other state in each back-end server.  Drawing requests are sent to
+  either windows or pixmaps on each back-end server.  This code is based
+  on Xnest and uses the existing Xinerama extension.
+
+
+  Input events can be taken from (1) devices attached to the back-end
+  server, (2) core devices attached directly to the Xdmx server, or (3)
+  from a ``console'' window on another X server.  Events for these
+  devices are gathered, processed and delivered to clients attached to
+  the Xdmx server.
+
+
+  An intuitive configuration format was developed to help the user
+  easily configure the multiple back-end X servers.  It was defined (see
+  grammar in Xdmx man page) and a parser was implemented that is used by
+  the Xdmx server and by a standalone xdmxconfig utility.  The parsing
+  support was implemented such that it can be easily factored out of the
+  X source tree for use with other tools (e.g., vdl).  Support for
+  converting legacy vdl-format configuration files to the DMX format is
+  provided by the vdltodmx utility.
+
+
+  Originally, the configuration file was going to be a subsection of
+  XFree86's XF86Config file, but that was not possible since Xdmx is a
+  completely separate X server.  Thus, a separate config file format was
+  developed.  In addition, a graphical configuration tool, xdmxconfig,
+  was developed to allow the user to create and arrange the screens in
+  the configuration file.  The --ccoonnffiiggffiillee and --ccoonnffiigg command-line
+  options can be used to start Xdmx using a configuration file.
+
+
+  An extension that enables remote input testing is required for the X
+  Test Suite to function.  During this phase, this extension (XTEST) was
+  implemented in the Xdmx server.  The results from running the X Test
+  Suite are described in detail below.
+
+
+  BB..11..33..  XX TTeesstt SSuuiittee
+
+  BB..11..33..11..  IInnttrroodduuccttiioonn
+
+  The X Test Suite contains tests that verify Xlib functions operate
+  correctly.  The test suite is designed to run on a single X server;
+  however, since X applications will not be able to tell the difference
+  between the DMX server and a standard X server, the X Test Suite
+  should also run on the DMX server.
+
+  The Xdmx server was tested with the X Test Suite, and the existing
+  failures are noted in this section.  To put these results in
+  perspective, we first discuss expected X Test failures and how errors
+  in underlying systems can impact Xdmx test results.
+
+
+  BB..11..33..22..  EExxppeecctteedd FFaaiilluurreess ffoorr aa SSiinnggllee HHeeaadd
+
+  A correctly implemented X server with a single screen is expected to
+  fail certain X Test tests.  The following well-known errors occur
+  because of rounding error in the X server code:
+
+  XDrawArc: Tests 42, 63, 66, 73
+  XDrawArcs: Tests 45, 66, 69, 76
+
+
+
+  The following failures occur because of the high-level X server
+  implementation:
+
+  XLoadQueryFont: Test 1
+  XListFontsWithInfo: Tests 3, 4
+  XQueryFont: Tests 1, 2
+
+
+
+  The following test fails when running the X server as root under Linux
+  because of the way directory modes are interpreted:
+
+  XWriteBitmapFile: Test 3
+
+
+
+  Depending on the video card used for the back-end, other failures may
+  also occur because of bugs in the low-level driver implementation.
+  Over time, failures of this kind are usually fixed by XFree86, but
+  will show up in Xdmx testing until then.
+
+
+  BB..11..33..33..  EExxppeecctteedd FFaaiilluurreess ffoorr XXiinneerraammaa
+
+  Xinerama fails several X Test Suite tests because of design decisions
+  made for the current implementation of Xinerama.  Over time, many of
+  these errors will be corrected by XFree86 and the group working on a
+  new Xinerama implementation.  Therefore, Xdmx will also share X Suite
+  Test failures with Xinerama.
+
+  We may be able to fix or work-around some of these failures at the
+  Xdmx level, but this will require additional exploration that was not
+  part of Phase I.
+
+  Xinerama is constantly improving, and the list of Xinerama-related
+  failures depends on XFree86 version and the underlying graphics
+  hardware.  We tested with a variety of hardware, including nVidia, S3,
+  ATI Radeon, and Matrox G400 (in dual-head mode).  The list below
+  includes only those failures that appear to be from the Xinerama
+  layer, and does not include failures listed in the previous section,
+  or failures that appear to be from the low-level graphics driver
+  itself:
+
+  These failures were noted with multiple Xinerama configurations:
+
+  XCopyPlane: Tests 13, 22, 31 (well-known Xinerama implementation issue)
+  XSetFontPath: Test 4
+  XGetDefault: Test 5
+  XMatchVisualInfo: Test 1
+
+
+
+  These failures were noted only when using one dual-head video card
+  with a 4.2.99.x XFree86 server:
+
+  XListPixmapFormats: Test 1
+  XDrawRectangles: Test 45
+
+
+
+  These failures were noted only when using two video cards from
+  different vendors with a 4.1.99.x XFree86 server:
+
+  XChangeWindowAttributes: Test 32
+  XCreateWindow: Test 30
+  XDrawLine: Test 22
+  XFillArc: Test 22
+  XChangeKeyboardControl: Tests 9, 10
+  XRebindKeysym: Test 1
+
+
+
+  BB..11..33..44..  AAddddiittiioonnaall FFaaiilluurreess ffrroomm XXddmmxx
+
+  When running Xdmx, no unexpected failures were noted.  Since the Xdmx
+  server is based on Xinerama, we expect to have most of the Xinerama
+  failures present in the Xdmx server.  Similarly, since the Xdmx server
+  must rely on the low-level device drivers on each back-end server, we
+  also expect that Xdmx will exhibit most of the back-end failures.
+  Here is a summary:
+
+  XListPixmapFormats: Test 1 (configuration dependent)
+  XChangeWindowAttributes: Test 32
+  XCreateWindow: Test 30
+  XCopyPlane: Test 13, 22, 31
+  XSetFontPath: Test 4
+  XGetDefault: Test 5 (configuration dependent)
+  XMatchVisualInfo: Test 1
+  XRebindKeysym: Test 1 (configuration dependent)
+
+
+
+  Note that this list is shorter than the combined list for Xinerama
+  because Xdmx uses different code paths to perform some Xinerama
+  operations.  Further, some Xinerama failures have been fixed in the
+  XFree86 4.2.99.x CVS repository.
+
+
+  BB..11..33..55..  SSuummmmaarryy aanndd FFuuttuurree WWoorrkk
+
+  Running the X Test Suite on Xdmx does not produce any failures that
+  cannot be accounted for by the underlying Xinerama subsystem used by
+  the front-end or by the low-level device-driver code running on the
+  back-end X servers.  The Xdmx server therefore is as ``correct'' as
+  possible with respect to the standard set of X Test Suite tests.
+
+  During the following phases, we will continue to verify Xdmx
+  correctness using the X Test Suite.  We may also use other tests
+  suites or write additional tests that run under the X Test Suite that
+  specifically verify the expected behavior of DMX.
+
+
+
+  BB..11..44..  FFoonnttss
+
+  In Phase I, fonts are handled directly by both the front-end and the
+  back-end servers, which is required since we must treat each back-end
+  server during this phase as a ``black box''.  What this requires is
+  that tthhee ffrroonntt-- aanndd bbaacckk--eenndd sseerrvveerrss mmuusstt sshhaarree tthhee eexxaacctt ssaammee ffoonntt
+  ppaatthh.  There are two ways to help make sure that all servers share the
+  same font path:
+
+
+  1. First, each server can be configured to use the same font server.
+     The font server, xfs, can be configured to serve fonts to multiple
+     X servers via TCP.
+
+  2. Second, each server can be configured to use the same font path and
+     either those font paths can be copied to each back-end machine or
+     they can be mounted (e.g., via NFS) on each back-end machine.
+
+
+  One additional concern is that a client program can set its own font
+  path, and if it does so, then that font path must be available on each
+  back-end machine.
+
+
+  The -fontpath command line option was added to allow users to
+  initialize the font path of the front end server.  This font path is
+  propagated to each back-end server when the default font is loaded.
+  If there are any problems, an error message is printed, which will
+  describe the problem and list the current font path.  For more
+  information about setting the font path, see the -fontpath option
+  description in the man page.
+
+
+  BB..11..55..  PPeerrffoorrmmaannccee
+
+  Phase I of development was not intended to optimize performance.  Its
+  focus was on completely and correctly handling the base X11 protocol
+  in the Xdmx server.  However, several insights were gained during
+  Phase I, which are listed here for reference during the next phase of
+  development.
+
+
+  1. Calls to XSync() can slow down rendering since it requires a
+     complete round trip to and from a back-end server.  This is
+     especially problematic when communicating over long haul networks.
+
+  2. Sending drawing requests to only the screens that they overlap
+     should improve performance.
+
+
+  BB..11..66..  PPiixxmmaappss
+
+  Pixmaps were originally expected to be handled entirely in the front-
+  end X server; however, it was found that this overly complicated the
+  rendering code and would have required sending potentially large
+  images to each back server that required them when copying from pixmap
+  to screen.  Thus, pixmap state is mirrored in the back-end server just
+  as it is with regular window state.  With this implementation, the
+  same rendering code that draws to windows can be used to draw to
+  pixmaps on the back-end server, and no large image transfers are
+  required to copy from pixmap to window.
+
+
+
+  BB..22..  PPhhaassee IIII
+
+  The second phase of development concentrates on performance
+  optimizations.  These optimizations are documented here, with x11perf
+  data to show how the optimizations improve performance.
+
+
+  All benchmarks were performed by running Xdmx on a dual processor
+  1.4GHz AMD Athlon machine with 1GB of RAM connecting over 100baseT to
+  two single-processor 1GHz Pentium III machines with 256MB of RAM and
+  ATI Rage 128 (RF) video cards.  The front end was running Linux
+  2.4.20-pre1-ac1 and the back ends were running Linux 2.4.7-10 and
+  version 4.2.99.1 of XFree86 pulled from the XFree86 CVS repository on
+  August 7, 2002.  All systems were running Red Hat Linux 7.2.
+
+
+  BB..22..11..  MMoovviinngg ffrroomm XXFFrreeee8866 44..11..9999..11 ttoo 44..22..00..00
+
+  For phase II, the working source tree was moved to the branch tagged
+  with dmx-1-0-branch and was updated from version 4.1.99.1 (20 August
+  2001) of the XFree86 sources to version 4.2.0.0 (18 January 2002).
+  After this update, the following tests were noted to be more than 10%
+  faster:
+
+  1.13   Fill 300x300 opaque stippled trapezoid (161x145 stipple)
+  1.16   Fill 1x1 tiled trapezoid (161x145 tile)
+  1.13   Fill 10x10 tiled trapezoid (161x145 tile)
+  1.17   Fill 100x100 tiled trapezoid (161x145 tile)
+  1.16   Fill 1x1 tiled trapezoid (216x208 tile)
+  1.20   Fill 10x10 tiled trapezoid (216x208 tile)
+  1.15   Fill 100x100 tiled trapezoid (216x208 tile)
+  1.37   Circulate Unmapped window (200 kids)
+
+
+
+  And the following tests were noted to be more than 10% slower:
+
+  0.88   Unmap window via parent (25 kids)
+  0.75   Circulate Unmapped window (4 kids)
+  0.79   Circulate Unmapped window (16 kids)
+  0.80   Circulate Unmapped window (25 kids)
+  0.82   Circulate Unmapped window (50 kids)
+  0.85   Circulate Unmapped window (75 kids)
+
+
+
+  These changes were not caused by any changes in the DMX system, and
+  may point to changes in the XFree86 tree or to tests that have more
+  "jitter" than most other x11perf tests.
+
+
+  BB..22..22..  GGlloobbaall cchhaannggeess
+
+  During the development of the Phase II DMX server, several global
+  changes were made.  These changes were also compared with the Phase I
+  server.  The following tests were noted to be more than 10% faster:
+
+
+
+  1.13   Fill 300x300 opaque stippled trapezoid (161x145 stipple)
+  1.15   Fill 1x1 tiled trapezoid (161x145 tile)
+  1.13   Fill 10x10 tiled trapezoid (161x145 tile)
+  1.17   Fill 100x100 tiled trapezoid (161x145 tile)
+  1.16   Fill 1x1 tiled trapezoid (216x208 tile)
+  1.19   Fill 10x10 tiled trapezoid (216x208 tile)
+  1.15   Fill 100x100 tiled trapezoid (216x208 tile)
+  1.15   Circulate Unmapped window (4 kids)
+
+
+
+  The following tests were noted to be more than 10% slower:
+
+  0.69   Scroll 10x10 pixels
+  0.68   Scroll 100x100 pixels
+  0.68   Copy 10x10 from window to window
+  0.68   Copy 100x100 from window to window
+  0.76   Circulate Unmapped window (75 kids)
+  0.83   Circulate Unmapped window (100 kids)
+
+
+
+  For the remainder of this analysis, the baseline of comparison will be
+  the Phase II deliverable with all optimizations disabled (unless
+  otherwise noted).  This will highlight how the optimizations in
+  isolation impact performance.
+
+
+  BB..22..33..  XXSSyynncc(()) BBaattcchhiinngg
+
+  During the Phase I implementation, XSync() was called after every
+  protocol request made by the DMX server.  This provided the DMX server
+  with an interactive feel, but defeated X11's protocol buffering system
+  and introduced round-trip wire latency into every operation.  During
+  Phase II, DMX was changed so that protocol requests are no longer
+  followed by calls to XSync().  Instead, the need for an XSync() is
+  noted, and XSync() calls are only made every 100mS or when the DMX
+  server specifically needs to make a call to guarantee interactivity.
+  With this new system, X11 buffers protocol as much as possible during
+  a 100mS interval, and many unnecessary XSync() calls are avoided.
+
+
+  Out of more than 300 x11perf tests, 8 tests became more than 100 times
+  faster, with 68 more than 50X faster, 114 more than 10X faster, and
+  181 more than 2X faster.  See table below for summary.
+
+
+  The following tests were noted to be more than 10% slower with XSync()
+  batching on:
+
+  0.88   500x500 tiled rectangle (161x145 tile)
+  0.89   Copy 500x500 from window to window
+
+
+
+  BB..22..44..  OOffffssccrreeeenn OOppttiimmiizzaattiioonn
+
+  Windows span one or more of the back-end servers' screens; however,
+  during Phase I development, windows were created on every back-end
+  server and every rendering request was sent to every window regardless
+  of whether or not that window was visible.  With the offscreen
+  optimization, the DMX server tracks when a window is completely off of
+  a back-end server's screen and, in that case, it does not send
+  rendering requests to those back-end windows.  This optimization saves
+  bandwidth between the front and back-end servers, and it reduces the
+  number of XSync() calls.  The performance tests were run on a DMX
+  system with only two back-end servers.  Greater performance gains will
+  be had as the number of back-end servers increases.
+
+
+  Out of more than 300 x11perf tests, 3 tests were at least twice as
+  fast, and 146 tests were at least 10% faster.  Two tests were more
+  than 10% slower with the offscreen optimization:
+
+  0.88   Hide/expose window via popup (4 kids)
+  0.89   Resize unmapped window (75 kids)
+
+
+
+  BB..22..55..  LLaazzyy WWiinnddooww CCrreeaattiioonn OOppttiimmiizzaattiioonn
+
+  As mentioned above, during Phase I, windows were created on every
+  back-end server even if they were not visible on that back-end.  With
+  the lazy window creation optimization, the DMX server does not create
+  windows on a back-end server until they are either visible or they
+  become the parents of a visible window.  This optimization builds on
+  the offscreen optimization (described above) and requires it to be
+  enabled.
+
+
+  The lazy window creation optimization works by creating the window
+  data structures in the front-end server when a client creates a
+  window, but delays creation of the window on the back-end server(s).
+  A private window structure in the DMX server saves the relevant window
+  data and tracks changes to the window's attributes and stacking order
+  for later use.  The only times a window is created on a back-end
+  server are (1) when it is mapped and is at least partially overlapping
+  the back-end server's screen (tracked by the offscreen optimization),
+  or (2) when the window becomes the parent of a previously visible
+  window.  The first case occurs when a window is mapped or when a
+  visible window is copied, moved or resized and now overlaps the back-
+  end server's screen.  The second case occurs when starting a window
+  manager after having created windows to which the window manager needs
+  to add decorations.
+
+
+  When either case occurs, a window on the back-end server is created
+  using the data saved in the DMX server's window private data
+  structure.  The stacking order is then adjusted to correctly place the
+  window on the back-end and lastly the window is mapped.  From this
+  time forward, the window is handled exactly as if the window had been
+  created at the time of the client's request.
+
+
+  Note that when a window is no longer visible on a back-end server's
+  screen (e.g., it is moved offscreen), the window is not destroyed;
+  rather, it is kept and reused later if the window once again becomes
+  visible on the back-end server's screen.  Originally with this
+  optimization, destroying windows was implemented but was later
+  rejected because it increased bandwidth when windows were opaquely
+  moved or resized, which is common in many window managers.
+
+
+
+  The performance tests were run on a DMX system with only two back-end
+  servers.  Greater performance gains will be had as the number of back-
+  end servers increases.
+
+
+  This optimization improved the following x11perf tests by more than
+  10%:
+
+  1.10   500x500 rectangle outline
+  1.12   Fill 100x100 stippled trapezoid (161x145 stipple)
+  1.20   Circulate Unmapped window (50 kids)
+  1.19   Circulate Unmapped window (75 kids)
+
+
+
+  BB..22..66..  SSuubbddiivviiddiinngg RReennddeerriinngg PPrriimmiittiivveess
+
+  X11 imaging requests transfer significant data between the client and
+  the X server.  During Phase I, the DMX server would then transfer the
+  image data to each back-end server.  Even with the offscreen
+  optimization (above), these requests still required transferring
+  significant data to each back-end server that contained a visible
+  portion of the window.  For example, if the client uses XPutImage() to
+  copy an image to a window that overlaps the entire DMX screen, then
+  the entire image is copied by the DMX server to every back-end server.
+
+
+  To reduce the amount of data transferred between the DMX server and
+  the back-end servers when XPutImage() is called, the image data is
+  subdivided and only the data that will be visible on a back-end
+  server's screen is sent to that back-end server.  Xinerama already
+  implements a subdivision algorithm for XGetImage() and no further
+  optimization was needed.
+
+
+  Other rendering primitives were analyzed, but the time required to
+  subdivide these primitives was a significant proportion of the time
+  required to send the entire rendering request to the back-end server,
+  so this optimization was rejected for the other rendering primitives.
+
+
+  Again, the performance tests were run on a DMX system with only two
+  back-end servers.  Greater performance gains will be had as the number
+  of back-end servers increases.
+
+
+  This optimization improved the following x11perf tests by more than
+  10%:
+
+  1.12   Fill 100x100 stippled trapezoid (161x145 stipple)
+  1.26   PutImage 10x10 square
+  1.83   PutImage 100x100 square
+  1.91   PutImage 500x500 square
+  1.40   PutImage XY 10x10 square
+  1.48   PutImage XY 100x100 square
+  1.50   PutImage XY 500x500 square
+  1.45   Circulate Unmapped window (75 kids)
+  1.74   Circulate Unmapped window (100 kids)
+
+
+
+  The following test was noted to be more than 10% slower with this
+  optimization:
+
+  0.88   10-pixel fill chord partial circle
+
+
+
+  BB..22..77..  SSuummmmaarryy ooff xx1111ppeerrff DDaattaa
+
+  With all of the optimizations on, 53 x11perf tests are more than 100X
+  faster than the unoptimized Phase II deliverable, with 69 more than
+  50X faster, 73 more than 10X faster, and 199 more than twice as fast.
+  No tests were more than 10% slower than the unoptimized Phase II
+  deliverable.  (Compared with the Phase I deliverable, only Circulate
+  Unmapped window (100 kids) was more than 10% slower than the Phase II
+  deliverable.  As noted above, this test seems to have wider
+  variability than other x11perf tests.)
+
+
+  The following table summarizes relative x11perf test changes for all
+  optimizations individually and collectively.  Note that some of the
+  optimizations have a synergistic effect when used together.
+
+
+
+  1: XSync() batching only
+  2: Off screen optimizations only
+  3: Window optimizations only
+  4: Subdivprims only
+  5: All optimizations
+
+      1     2    3    4      5 Operation
+  ------ ---- ---- ---- ------ ---------
+    2.14 1.85 1.00 1.00   4.13 Dot
+    1.67 1.80 1.00 1.00   3.31 1x1 rectangle
+    2.38 1.43 1.00 1.00   2.44 10x10 rectangle
+    1.00 1.00 0.92 0.98   1.00 100x100 rectangle
+    1.00 1.00 1.00 1.00   1.00 500x500 rectangle
+    1.83 1.85 1.05 1.06   3.54 1x1 stippled rectangle (8x8 stipple)
+    2.43 1.43 1.00 1.00   2.41 10x10 stippled rectangle (8x8 stipple)
+    0.98 1.00 1.00 1.00   1.00 100x100 stippled rectangle (8x8 stipple)
+    1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (8x8 stipple)
+    1.75 1.75 1.00 1.00   3.40 1x1 opaque stippled rectangle (8x8 stipple)
+    2.38 1.42 1.00 1.00   2.34 10x10 opaque stippled rectangle (8x8 stipple)
+    1.00 1.00 0.97 0.97   1.00 100x100 opaque stippled rectangle (8x8 stipple)
+    1.00 1.00 1.00 1.00   0.99 500x500 opaque stippled rectangle (8x8 stipple)
+    1.82 1.82 1.04 1.04   3.56 1x1 tiled rectangle (4x4 tile)
+    2.33 1.42 1.00 1.00   2.37 10x10 tiled rectangle (4x4 tile)
+    1.00 0.92 1.00 1.00   1.00 100x100 tiled rectangle (4x4 tile)
+    1.00 1.00 1.00 1.00   1.00 500x500 tiled rectangle (4x4 tile)
+    1.94 1.62 1.00 1.00   3.66 1x1 stippled rectangle (17x15 stipple)
+    1.74 1.28 1.00 1.00   1.73 10x10 stippled rectangle (17x15 stipple)
+    1.00 1.00 1.00 0.89   0.98 100x100 stippled rectangle (17x15 stipple)
+    1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (17x15 stipple)
+    1.94 1.62 1.00 1.00   3.67 1x1 opaque stippled rectangle (17x15 stipple)
+    1.69 1.26 1.00 1.00   1.66 10x10 opaque stippled rectangle (17x15 stipple)
+    1.00 0.95 1.00 1.00   1.00 100x100 opaque stippled rectangle (17x15 stipple)
+    1.00 1.00 1.00 1.00   0.97 500x500 opaque stippled rectangle (17x15 stipple)
+    1.93 1.61 0.99 0.99   3.69 1x1 tiled rectangle (17x15 tile)
+    1.73 1.27 1.00 1.00   1.72 10x10 tiled rectangle (17x15 tile)
+    1.00 1.00 1.00 1.00   0.98 100x100 tiled rectangle (17x15 tile)
+    1.00 1.00 0.97 0.97   1.00 500x500 tiled rectangle (17x15 tile)
+    1.95 1.63 1.00 1.00   3.83 1x1 stippled rectangle (161x145 stipple)
+    1.80 1.30 1.00 1.00   1.83 10x10 stippled rectangle (161x145 stipple)
+    0.97 1.00 1.00 1.00   1.01 100x100 stippled rectangle (161x145 stipple)
+    1.00 1.00 1.00 1.00   0.98 500x500 stippled rectangle (161x145 stipple)
+    1.95 1.63 1.00 1.00   3.56 1x1 opaque stippled rectangle (161x145 stipple)
+    1.65 1.25 1.00 1.00   1.68 10x10 opaque stippled rectangle (161x145 stipple)
+    1.00 1.00 1.00 1.00   1.01 100x100 opaque stippled rectangle (161x145...
+    1.00 1.00 1.00 1.00   0.97 500x500 opaque stippled rectangle (161x145...
+    1.95 1.63 0.98 0.99   3.80 1x1 tiled rectangle (161x145 tile)
+    1.67 1.26 1.00 1.00   1.67 10x10 tiled rectangle (161x145 tile)
+    1.13 1.14 1.14 1.14   1.14 100x100 tiled rectangle (161x145 tile)
+    0.88 1.00 1.00 1.00   0.99 500x500 tiled rectangle (161x145 tile)
+    1.93 1.63 1.00 1.00   3.53 1x1 tiled rectangle (216x208 tile)
+    1.69 1.26 1.00 1.00   1.66 10x10 tiled rectangle (216x208 tile)
+    1.00 1.00 1.00 1.00   1.00 100x100 tiled rectangle (216x208 tile)
+    1.00 1.00 1.00 1.00   1.00 500x500 tiled rectangle (216x208 tile)
+    1.82 1.70 1.00 1.00   3.38 1-pixel line segment
+    2.07 1.56 0.90 1.00   3.31 10-pixel line segment
+    1.29 1.10 1.00 1.00   1.27 100-pixel line segment
+    1.05 1.06 1.03 1.03   1.09 500-pixel line segment
+    1.30 1.13 1.00 1.00   1.29 100-pixel line segment (1 kid)
+    1.32 1.15 1.00 1.00   1.32 100-pixel line segment (2 kids)
+    1.33 1.16 1.00 1.00   1.33 100-pixel line segment (3 kids)
+    1.92 1.64 1.00 1.00   3.73 10-pixel dashed segment
+    1.34 1.16 1.00 1.00   1.34 100-pixel dashed segment
+    1.24 1.11 0.99 0.97   1.23 100-pixel double-dashed segment
+    1.72 1.77 1.00 1.00   3.25 10-pixel horizontal line segment
+    1.83 1.66 1.01 1.00   3.54 100-pixel horizontal line segment
+    1.86 1.30 1.00 1.00   1.84 500-pixel horizontal line segment
+    2.11 1.52 1.00 0.99   3.02 10-pixel vertical line segment
+    1.21 1.10 1.00 1.00   1.20 100-pixel vertical line segment
+    1.03 1.03 1.00 1.00   1.02 500-pixel vertical line segment
+    4.42 1.68 1.00 1.01   4.64 10x1 wide horizontal line segment
+    1.83 1.31 1.00 1.00   1.83 100x10 wide horizontal line segment
+    1.07 1.00 0.96 1.00   1.07 500x50 wide horizontal line segment
+    4.10 1.67 1.00 1.00   4.62 10x1 wide vertical line segment
+    1.50 1.24 1.06 1.06   1.48 100x10 wide vertical line segment
+    1.06 1.03 1.00 1.00   1.05 500x50 wide vertical line segment
+    2.54 1.61 1.00 1.00   3.61 1-pixel line
+    2.71 1.48 1.00 1.00   2.67 10-pixel line
+    1.19 1.09 1.00 1.00   1.19 100-pixel line
+    1.04 1.02 1.00 1.00   1.03 500-pixel line
+    2.68 1.51 0.98 1.00   3.17 10-pixel dashed line
+    1.23 1.11 0.99 0.99   1.23 100-pixel dashed line
+    1.15 1.08 1.00 1.00   1.15 100-pixel double-dashed line
+    2.27 1.39 1.00 1.00   2.23 10x1 wide line
+    1.20 1.09 1.00 1.00   1.20 100x10 wide line
+    1.04 1.02 1.00 1.00   1.04 500x50 wide line
+    1.52 1.45 1.00 1.00   1.52 100x10 wide dashed line
+    1.54 1.47 1.00 1.00   1.54 100x10 wide double-dashed line
+    1.97 1.30 0.96 0.95   1.95 10x10 rectangle outline
+    1.44 1.27 1.00 1.00   1.43 100x100 rectangle outline
+    3.22 2.16 1.10 1.09   3.61 500x500 rectangle outline
+    1.95 1.34 1.00 1.00   1.90 10x10 wide rectangle outline
+    1.14 1.14 1.00 1.00   1.13 100x100 wide rectangle outline
+    1.00 1.00 1.00 1.00   1.00 500x500 wide rectangle outline
+    1.57 1.72 1.00 1.00   3.03 1-pixel circle
+    1.96 1.35 1.00 1.00   1.92 10-pixel circle
+    1.21 1.07 0.86 0.97   1.20 100-pixel circle
+    1.08 1.04 1.00 1.00   1.08 500-pixel circle
+    1.39 1.19 1.03 1.03   1.38 100-pixel dashed circle
+    1.21 1.11 1.00 1.00   1.23 100-pixel double-dashed circle
+    1.59 1.28 1.00 1.00   1.58 10-pixel wide circle
+    1.22 1.12 0.99 1.00   1.22 100-pixel wide circle
+    1.06 1.04 1.00 1.00   1.05 500-pixel wide circle
+    1.87 1.84 1.00 1.00   1.85 100-pixel wide dashed circle
+    1.90 1.93 1.01 1.01   1.90 100-pixel wide double-dashed circle
+    2.13 1.43 1.00 1.00   2.32 10-pixel partial circle
+    1.42 1.18 1.00 1.00   1.42 100-pixel partial circle
+    1.92 1.85 1.01 1.01   1.89 10-pixel wide partial circle
+    1.73 1.67 1.00 1.00   1.73 100-pixel wide partial circle
+    1.36 1.95 1.00 1.00   2.64 1-pixel solid circle
+    2.02 1.37 1.00 1.00   2.03 10-pixel solid circle
+    1.19 1.09 1.00 1.00   1.19 100-pixel solid circle
+    1.02 0.99 1.00 1.00   1.01 500-pixel solid circle
+    1.74 1.28 1.00 0.88   1.73 10-pixel fill chord partial circle
+    1.31 1.13 1.00 1.00   1.31 100-pixel fill chord partial circle
+    1.67 1.31 1.03 1.03   1.72 10-pixel fill slice partial circle
+    1.30 1.13 1.00 1.00   1.28 100-pixel fill slice partial circle
+    2.45 1.49 1.01 1.00   2.71 10-pixel ellipse
+    1.22 1.10 1.00 1.00   1.22 100-pixel ellipse
+    1.09 1.04 1.00 1.00   1.09 500-pixel ellipse
+    1.90 1.28 1.00 1.00   1.89 100-pixel dashed ellipse
+    1.62 1.24 0.96 0.97   1.61 100-pixel double-dashed ellipse
+    2.43 1.50 1.00 1.00   2.42 10-pixel wide ellipse
+    1.61 1.28 1.03 1.03   1.60 100-pixel wide ellipse
+    1.08 1.05 1.00 1.00   1.08 500-pixel wide ellipse
+    1.93 1.88 1.00 1.00   1.88 100-pixel wide dashed ellipse
+    1.94 1.89 1.01 1.00   1.94 100-pixel wide double-dashed ellipse
+    2.31 1.48 1.00 1.00   2.67 10-pixel partial ellipse
+    1.38 1.17 1.00 1.00   1.38 100-pixel partial ellipse
+    2.00 1.85 0.98 0.97   1.98 10-pixel wide partial ellipse
+    1.89 1.86 1.00 1.00   1.89 100-pixel wide partial ellipse
+    3.49 1.60 1.00 1.00   3.65 10-pixel filled ellipse
+    1.67 1.26 1.00 1.00   1.67 100-pixel filled ellipse
+    1.06 1.04 1.00 1.00   1.06 500-pixel filled ellipse
+    2.38 1.43 1.01 1.00   2.32 10-pixel fill chord partial ellipse
+    2.06 1.30 1.00 1.00   2.05 100-pixel fill chord partial ellipse
+    2.27 1.41 1.00 1.00   2.27 10-pixel fill slice partial ellipse
+    1.98 1.33 1.00 0.97   1.97 100-pixel fill slice partial ellipse
+   57.46 1.99 1.01 1.00 114.92 Fill 1x1 equivalent triangle
+   56.94 1.98 1.01 1.00  73.89 Fill 10x10 equivalent triangle
+    6.07 1.75 1.00 1.00   6.07 Fill 100x100 equivalent triangle
+   51.12 1.98 1.00 1.00 102.81 Fill 1x1 trapezoid
+   51.42 1.82 1.01 1.00  94.89 Fill 10x10 trapezoid
+    6.47 1.80 1.00 1.00   6.44 Fill 100x100 trapezoid
+    1.56 1.28 1.00 0.99   1.56 Fill 300x300 trapezoid
+   51.27 1.97 0.96 0.97 102.54 Fill 1x1 stippled trapezoid (8x8 stipple)
+   51.73 2.00 1.02 1.02  67.92 Fill 10x10 stippled trapezoid (8x8 stipple)
+    5.36 1.72 1.00 1.00   5.36 Fill 100x100 stippled trapezoid (8x8 stipple)
+    1.54 1.26 1.00 1.00   1.59 Fill 300x300 stippled trapezoid (8x8 stipple)
+   51.41 1.94 1.01 1.00 102.82 Fill 1x1 opaque stippled trapezoid (8x8 stipple)
+   50.71 1.95 0.99 1.00  65.44 Fill 10x10 opaque stippled trapezoid (8x8...
+    5.33 1.73 1.00 1.00   5.36 Fill 100x100 opaque stippled trapezoid (8x8...
+    1.58 1.25 1.00 1.00   1.58 Fill 300x300 opaque stippled trapezoid (8x8...
+   51.56 1.96 0.99 0.90 103.68 Fill 1x1 tiled trapezoid (4x4 tile)
+   51.59 1.99 1.01 1.01  62.25 Fill 10x10 tiled trapezoid (4x4 tile)
+    5.38 1.72 1.00 1.00   5.38 Fill 100x100 tiled trapezoid (4x4 tile)
+    1.54 1.25 1.00 0.99   1.58 Fill 300x300 tiled trapezoid (4x4 tile)
+   51.70 1.98 1.01 1.01 103.98 Fill 1x1 stippled trapezoid (17x15 stipple)
+   44.86 1.97 1.00 1.00  44.86 Fill 10x10 stippled trapezoid (17x15 stipple)
+    2.74 1.56 1.00 1.00   2.73 Fill 100x100 stippled trapezoid (17x15 stipple)
+    1.29 1.14 1.00 1.00   1.27 Fill 300x300 stippled trapezoid (17x15 stipple)
+   51.41 1.96 0.96 0.95 103.39 Fill 1x1 opaque stippled trapezoid (17x15...
+   45.14 1.96 1.01 1.00  45.14 Fill 10x10 opaque stippled trapezoid (17x15...
+    2.68 1.56 1.00 1.00   2.68 Fill 100x100 opaque stippled trapezoid (17x15...
+    1.26 1.10 1.00 1.00   1.28 Fill 300x300 opaque stippled trapezoid (17x15...
+   51.13 1.97 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (17x15 tile)
+   47.58 1.96 1.00 1.00  47.86 Fill 10x10 tiled trapezoid (17x15 tile)
+    2.74 1.56 1.00 1.00   2.74 Fill 100x100 tiled trapezoid (17x15 tile)
+    1.29 1.14 1.00 1.00   1.28 Fill 300x300 tiled trapezoid (17x15 tile)
+   51.13 1.97 0.99 0.97 103.39 Fill 1x1 stippled trapezoid (161x145 stipple)
+   45.14 1.97 1.00 1.00  44.29 Fill 10x10 stippled trapezoid (161x145 stipple)
+    3.02 1.77 1.12 1.12   3.38 Fill 100x100 stippled trapezoid (161x145 stipple)
+    1.31 1.13 1.00 1.00   1.30 Fill 300x300 stippled trapezoid (161x145 stipple)
+   51.27 1.97 1.00 1.00 103.10 Fill 1x1 opaque stippled trapezoid (161x145...
+   45.01 1.97 1.00 1.00  45.01 Fill 10x10 opaque stippled trapezoid (161x145...
+    2.67 1.56 1.00 1.00   2.69 Fill 100x100 opaque stippled trapezoid (161x145..
+    1.29 1.13 1.00 1.01   1.27 Fill 300x300 opaque stippled trapezoid (161x145..
+   51.41 1.96 1.00 0.99 103.39 Fill 1x1 tiled trapezoid (161x145 tile)
+   45.01 1.96 0.98 1.00  45.01 Fill 10x10 tiled trapezoid (161x145 tile)
+    2.62 1.36 1.00 1.00   2.69 Fill 100x100 tiled trapezoid (161x145 tile)
+    1.27 1.13 1.00 1.00   1.22 Fill 300x300 tiled trapezoid (161x145 tile)
+   51.13 1.98 1.00 1.00 103.39 Fill 1x1 tiled trapezoid (216x208 tile)
+   45.14 1.97 1.01 0.99  45.14 Fill 10x10 tiled trapezoid (216x208 tile)
+    2.62 1.55 1.00 1.00   2.71 Fill 100x100 tiled trapezoid (216x208 tile)
+    1.28 1.13 1.00 1.00   1.20 Fill 300x300 tiled trapezoid (216x208 tile)
+   50.71 1.95 1.00 1.00  54.70 Fill 10x10 equivalent complex polygon
+    5.51 1.71 0.96 0.98   5.47 Fill 100x100 equivalent complex polygons
+    8.39 1.97 1.00 1.00  16.75 Fill 10x10 64-gon (Convex)
+    8.38 1.83 1.00 1.00   8.43 Fill 100x100 64-gon (Convex)
+    8.50 1.96 1.00 1.00  16.64 Fill 10x10 64-gon (Complex)
+    8.26 1.83 1.00 1.00   8.35 Fill 100x100 64-gon (Complex)
+   14.09 1.87 1.00 1.00  14.05 Char in 80-char line (6x13)
+   11.91 1.87 1.00 1.00  11.95 Char in 70-char line (8x13)
+   11.16 1.85 1.01 1.00  11.10 Char in 60-char line (9x15)
+   10.09 1.78 1.00 1.00  10.09 Char16 in 40-char line (k14)
+    6.15 1.75 1.00 1.00   6.31 Char16 in 23-char line (k24)
+   11.92 1.90 1.03 1.03  11.88 Char in 80-char line (TR 10)
+    8.18 1.78 1.00 0.99   8.17 Char in 30-char line (TR 24)
+   42.83 1.44 1.01 1.00  42.11 Char in 20/40/20 line (6x13, TR 10)
+   27.45 1.43 1.01 1.01  27.45 Char16 in 7/14/7 line (k14, k24)
+   12.13 1.85 1.00 1.00  12.05 Char in 80-char image line (6x13)
+   10.00 1.84 1.00 1.00  10.00 Char in 70-char image line (8x13)
+    9.18 1.83 1.00 1.00   9.12 Char in 60-char image line (9x15)
+    9.66 1.82 0.98 0.95   9.66 Char16 in 40-char image line (k14)
+    5.82 1.72 1.00 1.00   5.99 Char16 in 23-char image line (k24)
+    8.70 1.80 1.00 1.00   8.65 Char in 80-char image line (TR 10)
+    4.67 1.66 1.00 1.00   4.67 Char in 30-char image line (TR 24)
+   84.43 1.47 1.00 1.00 124.18 Scroll 10x10 pixels
+    3.73 1.50 1.00 0.98   3.73 Scroll 100x100 pixels
+    1.00 1.00 1.00 1.00   1.00 Scroll 500x500 pixels
+   84.43 1.51 1.00 1.00 134.02 Copy 10x10 from window to window
+    3.62 1.51 0.98 0.98   3.62 Copy 100x100 from window to window
+    0.89 1.00 1.00 1.00   1.00 Copy 500x500 from window to window
+   57.06 1.99 1.00 1.00  88.64 Copy 10x10 from pixmap to window
+    2.49 2.00 1.00 1.00   2.48 Copy 100x100 from pixmap to window
+    1.00 0.91 1.00 1.00   0.98 Copy 500x500 from pixmap to window
+    2.04 1.01 1.00 1.00   2.03 Copy 10x10 from window to pixmap
+    1.05 1.00 1.00 1.00   1.05 Copy 100x100 from window to pixmap
+    1.00 1.00 0.93 1.00   1.04 Copy 500x500 from window to pixmap
+   58.52 1.03 1.03 1.02  57.95 Copy 10x10 from pixmap to pixmap
+    2.40 1.00 1.00 1.00   2.45 Copy 100x100 from pixmap to pixmap
+    1.00 1.00 1.00 1.00   1.00 Copy 500x500 from pixmap to pixmap
+   51.57 1.92 1.00 1.00  85.75 Copy 10x10 1-bit deep plane
+    6.37 1.75 1.01 1.01   6.37 Copy 100x100 1-bit deep plane
+    1.26 1.11 1.00 1.00   1.24 Copy 500x500 1-bit deep plane
+    4.23 1.63 0.98 0.97   4.38 Copy 10x10 n-bit deep plane
+    1.04 1.02 1.00 1.00   1.04 Copy 100x100 n-bit deep plane
+    1.00 1.00 1.00 1.00   1.00 Copy 500x500 n-bit deep plane
+    6.45 1.98 1.00 1.26  12.80 PutImage 10x10 square
+    1.10 1.87 1.00 1.83   2.11 PutImage 100x100 square
+    1.02 1.93 1.00 1.91   1.91 PutImage 500x500 square
+    4.17 1.78 1.00 1.40   7.18 PutImage XY 10x10 square
+    1.27 1.49 0.97 1.48   2.10 PutImage XY 100x100 square
+    1.00 1.50 1.00 1.50   1.52 PutImage XY 500x500 square
+    1.07 1.01 1.00 1.00   1.06 GetImage 10x10 square
+    1.01 1.00 1.00 1.00   1.01 GetImage 100x100 square
+    1.00 1.00 1.00 1.00   1.00 GetImage 500x500 square
+    1.56 1.00 0.99 0.97   1.56 GetImage XY 10x10 square
+    1.02 1.00 1.00 1.00   1.02 GetImage XY 100x100 square
+    1.00 1.00 1.00 1.00   1.00 GetImage XY 500x500 square
+    1.00 1.00 1.01 0.98   0.95 X protocol NoOperation
+    1.02 1.03 1.04 1.03   1.00 QueryPointer
+    1.03 1.02 1.04 1.03   1.00 GetProperty
+  100.41 1.51 1.00 1.00 198.76 Change graphics context
+   45.81 1.00 0.99 0.97  57.10 Create and map subwindows (4 kids)
+   78.45 1.01 1.02 1.02  63.07 Create and map subwindows (16 kids)
+   73.91 1.01 1.00 1.00  56.37 Create and map subwindows (25 kids)
+   73.22 1.00 1.00 1.00  49.07 Create and map subwindows (50 kids)
+   72.36 1.01 0.99 1.00  32.14 Create and map subwindows (75 kids)
+   70.34 1.00 1.00 1.00  30.12 Create and map subwindows (100 kids)
+   55.00 1.00 1.00 0.99  23.75 Create and map subwindows (200 kids)
+   55.30 1.01 1.00 1.00 141.03 Create unmapped window (4 kids)
+   55.38 1.01 1.01 1.00 163.25 Create unmapped window (16 kids)
+   54.75 0.96 1.00 0.99 166.95 Create unmapped window (25 kids)
+   54.83 1.00 1.00 0.99 178.81 Create unmapped window (50 kids)
+   55.38 1.01 1.01 1.00 181.20 Create unmapped window (75 kids)
+   55.38 1.01 1.01 1.00 181.20 Create unmapped window (100 kids)
+   54.87 1.01 1.01 1.00 182.05 Create unmapped window (200 kids)
+   28.13 1.00 1.00 1.00  30.75 Map window via parent (4 kids)
+   36.14 1.01 1.01 1.01  32.58 Map window via parent (16 kids)
+   26.13 1.00 0.98 0.95  29.85 Map window via parent (25 kids)
+   40.07 1.00 1.01 1.00  27.57 Map window via parent (50 kids)
+   23.26 0.99 1.00 1.00  18.23 Map window via parent (75 kids)
+   22.91 0.99 1.00 0.99  16.52 Map window via parent (100 kids)
+   27.79 1.00 1.00 0.99  12.50 Map window via parent (200 kids)
+   22.35 1.00 1.00 1.00  56.19 Unmap window via parent (4 kids)
+    9.57 1.00 0.99 1.00  89.78 Unmap window via parent (16 kids)
+   80.77 1.01 1.00 1.00 103.85 Unmap window via parent (25 kids)
+   96.34 1.00 1.00 1.00 116.06 Unmap window via parent (50 kids)
+   99.72 1.00 1.00 1.00 124.93 Unmap window via parent (75 kids)
+  112.36 1.00 1.00 1.00 125.27 Unmap window via parent (100 kids)
+  105.41 1.00 1.00 0.99 120.00 Unmap window via parent (200 kids)
+   51.29 1.03 1.02 1.02  74.19 Destroy window via parent (4 kids)
+   86.75 0.99 0.99 0.99 116.87 Destroy window via parent (16 kids)
+  106.43 1.01 1.01 1.01 127.49 Destroy window via parent (25 kids)
+  120.34 1.01 1.01 1.00 140.11 Destroy window via parent (50 kids)
+  126.67 1.00 0.99 0.99 145.00 Destroy window via parent (75 kids)
+  126.11 1.01 1.01 1.00 140.56 Destroy window via parent (100 kids)
+  128.57 1.01 1.00 1.00 137.91 Destroy window via parent (200 kids)
+   16.04 0.88 1.00 1.00  20.36 Hide/expose window via popup (4 kids)
+   19.04 1.01 1.00 1.00  23.48 Hide/expose window via popup (16 kids)
+   19.22 1.00 1.00 1.00  20.44 Hide/expose window via popup (25 kids)
+   17.41 1.00 0.91 0.97  17.68 Hide/expose window via popup (50 kids)
+   17.29 1.01 1.00 1.01  17.07 Hide/expose window via popup (75 kids)
+   16.74 1.00 1.00 1.00  16.17 Hide/expose window via popup (100 kids)
+   10.30 1.00 1.00 1.00  10.51 Hide/expose window via popup (200 kids)
+   16.48 1.01 1.00 1.00  26.05 Move window (4 kids)
+   17.01 0.95 1.00 1.00  23.97 Move window (16 kids)
+   16.95 1.00 1.00 1.00  22.90 Move window (25 kids)
+   16.05 1.01 1.00 1.00  21.32 Move window (50 kids)
+   15.58 1.00 0.98 0.98  19.44 Move window (75 kids)
+   14.98 1.02 1.03 1.03  18.17 Move window (100 kids)
+   10.90 1.01 1.01 1.00  12.68 Move window (200 kids)
+   49.42 1.00 1.00 1.00 198.27 Moved unmapped window (4 kids)
+   50.72 0.97 1.00 1.00 193.66 Moved unmapped window (16 kids)
+   50.87 1.00 0.99 1.00 195.09 Moved unmapped window (25 kids)
+   50.72 1.00 1.00 1.00 189.34 Moved unmapped window (50 kids)
+   50.87 1.00 1.00 1.00 191.33 Moved unmapped window (75 kids)
+   50.87 1.00 1.00 0.90 186.71 Moved unmapped window (100 kids)
+   50.87 1.00 1.00 1.00 179.19 Moved unmapped window (200 kids)
+   41.04 1.00 1.00 1.00  56.61 Move window via parent (4 kids)
+   69.81 1.00 1.00 1.00 130.82 Move window via parent (16 kids)
+   95.81 1.00 1.00 1.00 141.92 Move window via parent (25 kids)
+   95.98 1.00 1.00 1.00 149.43 Move window via parent (50 kids)
+   96.59 1.01 1.01 1.00 153.98 Move window via parent (75 kids)
+   97.19 1.00 1.00 1.00 157.30 Move window via parent (100 kids)
+   96.67 1.00 0.99 0.96 159.44 Move window via parent (200 kids)
+   17.75 1.01 1.00 1.00  27.61 Resize window (4 kids)
+   17.94 1.00 1.00 0.99  25.42 Resize window (16 kids)
+   17.92 1.01 1.00 1.00  24.47 Resize window (25 kids)
+   17.24 0.97 1.00 1.00  24.14 Resize window (50 kids)
+   16.81 1.00 1.00 0.99  22.75 Resize window (75 kids)
+   16.08 1.00 1.00 1.00  21.20 Resize window (100 kids)
+   12.92 1.00 0.99 1.00  16.26 Resize window (200 kids)
+   52.94 1.01 1.00 1.00 327.12 Resize unmapped window (4 kids)
+   53.60 1.01 1.01 1.01 333.71 Resize unmapped window (16 kids)
+   52.99 1.00 1.00 1.00 337.29 Resize unmapped window (25 kids)
+   51.98 1.00 1.00 1.00 329.38 Resize unmapped window (50 kids)
+   53.05 0.89 1.00 1.00 322.60 Resize unmapped window (75 kids)
+   53.05 1.00 1.00 1.00 318.08 Resize unmapped window (100 kids)
+   53.11 1.00 1.00 0.99 306.21 Resize unmapped window (200 kids)
+   16.76 1.00 0.96 1.00  19.46 Circulate window (4 kids)
+   17.24 1.00 1.00 0.97  16.24 Circulate window (16 kids)
+   16.30 1.03 1.03 1.03  15.85 Circulate window (25 kids)
+   13.45 1.00 1.00 1.00  14.90 Circulate window (50 kids)
+   12.91 1.00 1.00 1.00  13.06 Circulate window (75 kids)
+   11.30 0.98 1.00 1.00  11.03 Circulate window (100 kids)
+    7.58 1.01 1.01 0.99   7.47 Circulate window (200 kids)
+    1.01 1.01 0.98 1.00   0.95 Circulate Unmapped window (4 kids)
+    1.07 1.07 1.01 1.07   1.02 Circulate Unmapped window (16 kids)
+    1.04 1.09 1.06 1.05   0.97 Circulate Unmapped window (25 kids)
+    1.04 1.23 1.20 1.18   1.05 Circulate Unmapped window (50 kids)
+    1.18 1.53 1.19 1.45   1.24 Circulate Unmapped window (75 kids)
+    1.08 1.02 1.01 1.74   1.01 Circulate Unmapped window (100 kids)
+    1.01 1.12 0.98 0.91   0.97 Circulate Unmapped window (200 kids)
+
+
+
+  BB..22..88..  PPrrooffiilliinngg wwiitthh OOPPrrooffiillee
+
+  OProfile (available from http://oprofile.sourceforge.net/) is a
+  system-wide profiler for Linux systems that uses processor-level
+  counters to collect sampling data.  OProfile can provide information
+  that is similar to that provided by gprof, but without the necessity
+  of recompiling the program with special instrumentation (i.e.,
+  OProfile can collect statistical profiling information about optimized
+  programs).  A test harness was developed to collect OProfile data for
+  each x11perf test individually.
+
+
+  Test runs were performed using the RETIRED_INSNS counter on the AMD
+  Athlon and the CPU_CLK_HALTED counter on the Intel Pentium III (with a
+  test configuration different from the one described above).  We have
+  examined OProfile output and have compared it with gprof output.  This
+  investigation has not produced results that yield performance
+  increases in x11perf numbers.
+
+
+
+  BB..22..99..  XX TTeesstt SSuuiittee
+
+  The X Test Suite was run on the fully optimized DMX server using the
+  configuration described above.  The following failures were noted:
+
+  XListPixmapFormats: Test 1              [1]
+  XChangeWindowAttributes: Test 32        [1]
+  XCreateWindow: Test 30                  [1]
+  XFreeColors: Test 4                     [3]
+  XCopyArea: Test 13, 17, 21, 25, 30      [2]
+  XCopyPlane: Test 11, 15, 27, 31         [2]
+  XSetFontPath: Test 4                    [1]
+  XChangeKeyboardControl: Test 9, 10      [1]
+
+  [1] Previously documented errors expected from the Xinerama
+      implementation (see Phase I discussion).
+  [2] Newly noted errors that have been verified as expected
+      behavior of the Xinerama implementation.
+  [3] Newly noted error that has been verified as a Xinerama
+      implementation bug.
+
+
+
+  BB..33..  PPhhaassee IIIIII
+
+  During the third phase of development, support was provided for the
+  following extensions: SHAPE, RENDER, XKEYBOARD, XInput.
+
+
+  BB..33..11..  SSHHAAPPEE
+
+  The SHAPE extension is supported.  Test applications (e.g., xeyes and
+  oclock) and window managers that make use of the SHAPE extension will
+  work as expected.
+
+
+  BB..33..22..  RREENNDDEERR
+
+  The RENDER extension is supported.  The version included in the DMX
+  CVS tree is version 0.2, and this version is fully supported by Xdmx.
+  Applications using only version 0.2 functions will work correctly;
+  however, some apps that make use of functions from later versions do
+  not properly check the extension's major/minor version numbers.  These
+  apps will fail with a Bad Implementation error when using post-version
+  0.2 functions.  This is expected behavior.  When the DMX CVS tree is
+  updated to include newer versions of RENDER, support for these newer
+  functions will be added to the DMX X server.
+
+
+  BB..33..33..  XXKKEEYYBBOOAARRDD
+
+  The XKEYBOARD extension is supported.  If present on the back-end X
+  servers, the XKEYBOARD extension will be used to obtain information
+  about the type of the keyboard for initialization.  Otherwise, the
+  keyboard will be initialized using defaults.  Note that this departs
+  from older behavior: when Xdmx is compiled without XKEYBOARD support,
+  the map from the back-end X server will be preserved.  With XKEYBOARD
+  support, the map is not preserved because better information and
+  control of the keyboard is available.
+
+
+  BB..33..44..  XXIInnppuutt
+
+  The XInput extension is supported.  Any device can be used as a core
+  device and be used as an XInput extension device, with the exception
+  of core devices on the back-end servers.  This limitation is present
+  because cursor handling on the back-end requires that the back-end
+  cursor sometimes track the Xdmx core cursor -- behavior that is
+  incompatible with using the back-end pointer as a non-core device.
+
+
+  Currently, back-end extension devices are not available as Xdmx
+  extension devices, but this limitation should be removed in the
+  future.
+
+
+  To demonstrate the XInput extension, and to provide more examples for
+  low-level input device driver writers, USB device drivers have been
+  written for mice (usb-mou), keyboards (usb-kbd), and non-mouse/non-
+  keyboard USB devices (usb-oth).  Please see the man page for
+  information on Linux kernel drivers that are required for using these
+  Xdmx drivers.
+
+
+  BB..33..55..  DDPPMMSS
+
+  The DPMS extension is exported but does not do anything at this time.
+
+
+  BB..33..66..  OOtthheerr EExxtteennssiioonnss
+
+  The LBX, SECURITY, XC-APPGROUP, and XFree86-Bigfont extensions do not
+  require any special Xdmx support and have been exported.
+
+
+  The BIG-REQUESTS, DEC-XTRAP, DOUBLE-BUFFER, Extended-Visual-
+  Information, FontCache, GLX, MIT-SCREEN-SAVER, MIT-SHM, MIT-SUNDRY-
+  NONSTANDARD, RECORD, SECURITY, SGI-GLX, SYNC, TOG-CUP, X-Resource, XC-
+  MISC, XFree86-DGA, XFree86-DRI, XFree86-Misc,
+  XFree86-VidModeExtension, and XVideo extensions are _n_o_t supported at
+  this time, but will be evaluated for inclusion in future DMX releases.
+  SSeeee bbeellooww ffoorr aaddddiittiioonnaall wwoorrkk oonn eexxtteennssiioonnss aafftteerr PPhhaassee IIIIII..
+
+
+  BB..44..  PPhhaassee IIVV
+
+  BB..44..11..  MMoovviinngg ttoo XXFFrreeee8866 44..33..00
+
+  For Phase IV, the recent release of XFree86 4.3.0 (27 February 2003)
+  was merged onto the dmx.sourceforge.net CVS trunk and all work is
+  proceeding using this tree.
+
+
+  BB..44..22..  EExxtteennssiioonnss
+
+  BB..44..22..11..  XXCC--MMIISSCC ((ssuuppppoorrtteedd))
+
+  XC-MISC is used internally by the X library to recycle XIDs from the X
+  server.  This is important for long-running X server sessions.  Xdmx
+  supports this extension.  The X Test Suite passed and failed the exact
+  same tests before and after this extension was enabled.
+
+
+  BB..44..22..22..  EExxtteennddeedd--VViissuuaall--IInnffoorrmmaattiioonn ((ssuuppppoorrtteedd))
+
+  The Extended-Visual-Information extension provides a method for an X
+  client to obtain detailed visual information.  Xdmx supports this
+  extension.  It was tested using the hw/dmx/examples/evi example
+  program.  NNoottee tthhaatt tthhiiss eexxtteennssiioonn iiss nnoott XXiinneerraammaa--aawwaarree -- it will
+  return visual information for each screen even though Xinerama is
+  causing the X server to export a single logical screen.
+
+
+  BB..44..22..33..  RREESS ((ssuuppppoorrtteedd))
+
+  The X-Resource extension provides a mechanism for a client to obtain
+  detailed information about the resources used by other clients.  This
+  extension was tested with the hw/dmx/examples/res program.  The X Test
+  Suite passed and failed the exact same tests before and after this
+  extension was enabled.
+
+
+  BB..44..22..44..  BBIIGG--RREEQQUUEESSTTSS ((ssuuppppoorrtteedd))
+
+  This extension enables the X11 protocol to handle requests longer than
+  262140 bytes.  The X Test Suite passed and failed the exact same tests
+  before and after this extension was enabled.
+
+
+  BB..44..22..55..  XXSSYYNNCC ((ssuuppppoorrtteedd))
+
+  This extension provides facilities for two different X clients to
+  synchronize their requests.  This extension was minimally tested with
+  xdpyinfo and the X Test Suite passed and failed the exact same tests
+  before and after this extension was enabled.
+
+
+  BB..44..22..66..  XXTTEESSTT,, RREECCOORRDD,, DDEECC--XXTTRRAAPP ((ssuuppppoorrtteedd)) aanndd XXTTeessttEExxtteennssiioonn11
+  ((nnoott ssuuppppoorrtteedd))
+
+  The XTEST and RECORD extension were developed by the X Consortium for
+  use in the X Test Suite and are supported as a standard in the X11R6
+  tree.  They are also supported in Xdmx.  When X Test Suite tests that
+  make use of the XTEST extension are run, Xdmx passes and fails exactly
+  the same tests as does a standard XFree86 X server.  When the rcrdtest
+  test (a part of the X Test Suite that verifies the RECORD extension)
+  is run, Xdmx passes and fails exactly the same tests as does a
+  standard XFree86 X server.
+
+
+  There are two older XTEST-like extensions: DEC-XTRAP and
+  XTestExtension1.  The XTestExtension1 extension was developed for use
+  by the X Testing Consortium for use with a test suite that eventually
+  became (part of?) the X Test Suite.  Unlike XTEST, which only allows
+  events to be sent to the server, the XTestExtension1 extension also
+  allowed events to be recorded (similar to the RECORD extension).  The
+  second is the DEC-XTRAP extension that was developed by the Digital
+  Equipment Corporation.
+
+
+  The DEC-XTRAP extension is available from Xdmx and has been tested
+  with the xtrap* tools which are distributed as standard X11R6 clients.
+
+
+  The XTestExtension1 is _n_o_t supported because it does not appear to be
+  used by any modern X clients (the few that support it also support
+  XTEST) and because there are no good methods available for testing
+  that it functions correctly (unlike XTEST and DEC-XTRAP, the code for
+  XTestExtension1 is not part of the standard X server source tree, so
+  additional testing is important).
+
+
+  Most of these extensions are documented in the X11R6 source tree.
+  Further, several original papers exist that this author was unable to
+  locate -- for completeness and historical interest, citations are
+  provide:
+
+     XXRREECCOORRDD
+        Martha Zimet. Extending X For Recording.  8th Annual X Technical
+        Conference Boston, MA January 24-26, 1994.
+
+     DDEECC--XXTTRRAAPP
+        Dick Annicchiarico, Robert Chesler, Alan Jamison. XTrap
+        Architecture. Digital Equipment Corporation, July 1991.
+
+     XXTTeessttEExxtteennssiioonn11
+        Larry Woestman. X11 Input Synthesis Extension Proposal. Hewlett
+        Packard, November 1991.
+
+
+  BB..44..22..77..  MMIITT--MMIISSCC ((nnoott ssuuppppoorrtteedd))
+
+  The MIT-MISC extension is used to control a bug-compatibility flag
+  that provides compatibility with xterm programs from X11R1 and X11R2.
+  There does not appear to be a single client available that makes use
+  of this extension and there is not way to verify that it works
+  correctly.  The Xdmx server does _n_o_t support MIT-MISC.
+
+
+  BB..44..22..88..  SSCCRREEEENNSSAAVVEERR ((nnoott ssuuppppoorrtteedd))
+
+  This extension provides special support for the X screen saver.  It
+  was tested with beforelight, which appears to be the only client that
+  works with it.  When Xinerama was not active, beforelight behaved as
+  expected.  However, when Xinerama was active, beforelight did not
+  behave as expected.  Further, when this extension is not active,
+  xscreensaver (a widely-used X screen saver program) did not behave as
+  expected.  Since this extension is not Xinerama-aware and is not
+  commonly used with expected results by clients, we have left this
+  extension disabled at this time.
+
+  BB..44..22..99..  GGLLXX ((ssuuppppoorrtteedd))
+
+  The GLX extension provides OpenGL and GLX windowing support.  In Xdmx,
+  the extension is called glxProxy, and it is Xinerama aware.  It works
+  by either feeding requests forward through Xdmx to each of the back-
+  end servers or handling them locally.  All rendering requests are
+  handled on the back-end X servers.  This code was donated to the DMX
+  project by SGI.  For the X Test Suite results comparison, see below.
+
+
+  BB..44..22..1100..  RREENNDDEERR ((ssuuppppoorrtteedd))
+
+  The X Rendering Extension (RENDER) provides support for digital image
+  composition.  Geometric and text rendering are supported.  RENDER is
+  partially Xinerama-aware, with text and the most basic compositing
+  operator; however, its higher level primitives (triangles, triangle
+  strips, and triangle fans) are not yet Xinerama-aware.  The RENDER
+  extension is still under development, and is currently at version 0.8.
+  Additional support will be required in DMX as more primitives and/or
+  requests are added to the extension.
+
+
+  There is currently no test suite for the X Rendering Extension;
+  however, there has been discussion of developing a test suite as the
+  extension matures.  When that test suite becomes available, additional
+  testing can be performed with Xdmx.  The X Test Suite passed and
+  failed the exact same tests before and after this extension was
+  enabled.
+
+
+  BB..44..22..1111..  SSuummmmaarryy
+
+  To summarize, the following extensions are currently supported: BIG-
+  REQUESTS, DEC-XTRAP, DMX, DPMS, Extended-Visual-Information, GLX, LBX,
+  RECORD, RENDER, SECURITY, SHAPE, SYNC, X-Resource, XC-APPGROUP, XC-
+  MISC, XFree86-Bigfont, XINERAMA, XInputExtension, XKEYBOARD, and
+  XTEST.
+
+
+  The following extensions are _n_o_t supported at this time: DOUBLE-
+  BUFFER, FontCache, MIT-SCREEN-SAVER, MIT-SHM, MIT-SUNDRY-NONSTANDARD,
+  TOG-CUP, XFree86-DGA, XFree86-Misc, XFree86-VidModeExtension,
+  XTestExtensionExt1, and XVideo.
+
+
+  BB..44..33..  AAddddiittiioonnaall TTeessttiinngg wwiitthh tthhee XX TTeesstt SSuuiittee
+
+  BB..44..33..11..  XXFFrreeee8866 wwiitthhoouutt XXTTEESSTT
+
+  After the release of XFree86 4.3.0, we retested the XFree86 X server
+  with and without using the XTEST extension.  When the XTEST extension
+  was _n_o_t used for testing, the XFree86 4.3.0 server running on our
+  usual test system with a Radeon VE card reported unexpected failures
+  in the following tests:
+
+  XListPixmapFormats: Test 1
+  XChangeKeyboardControl: Tests 9, 10
+  XGetDefault: Test 5
+  XRebindKeysym: Test 1
+
+
+
+  BB..44..33..22..  XXFFrreeee8866 wwiitthh XXTTEESSTT
+
+  When using the XTEST extension, the XFree86 4.3.0 server reported the
+  following errors:
+
+  XListPixmapFormats: Test 1
+  XChangeKeyboardControl: Tests 9, 10
+  XGetDefault: Test 5
+  XRebindKeysym: Test 1
+
+  XAllowEvents: Tests 20, 21, 24
+  XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
+  XGrabKey: Test 8
+  XSetPointerMapping: Test 3
+  XUngrabButton: Test 4
+
+
+
+  While these errors may be important, they will probably be fixed
+  eventually in the XFree86 source tree.  We are particularly interested
+  in demonstrating that the Xdmx server does not introduce additional
+  failures that are not known Xinerama failures.
+
+
+  BB..44..33..33..  XXddmmxx wwiitthh XXTTEESSTT,, wwiitthhoouutt XXiinneerraammaa,, wwiitthhoouutt GGLLXX
+
+  Without Xinerama, but using the XTEST extension, the following errors
+  were reported from Xdmx (note that these are the same as for the
+  XFree86 4.3.0, except that XGetDefault no longer fails):
+
+  XListPixmapFormats: Test 1
+  XChangeKeyboardControl: Tests 9, 10
+  XRebindKeysym: Test 1
+
+  XAllowEvents: Tests  20, 21, 24
+  XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
+  XGrabKey: Test 8
+  XSetPointerMapping: Test 3
+  XUngrabButton: Test 4
+
+
+
+  BB..44..33..44..  XXddmmxx wwiitthh XXTTEESSTT,, wwiitthh XXiinneerraammaa,, wwiitthhoouutt GGLLXX
+
+  With Xinerama, using the XTEST extension, the following errors were
+  reported from Xdmx:
+
+  XListPixmapFormats: Test 1
+  XChangeKeyboardControl: Tests 9, 10
+  XRebindKeysym: Test 1
+
+  XAllowEvents: Tests 20, 21, 24
+  XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
+  XGrabKey: Test 8
+  XSetPointerMapping: Test 3
+  XUngrabButton: Test 4
+
+  XCopyPlane: Tests 13, 22, 31 (well-known XTEST/Xinerama interaction issue)
+  XDrawLine: Test 67
+  XDrawLines: Test 91
+  XDrawSegments: Test 68
+
+
+
+  Note that the first two sets of errors are the same as for the XFree86
+  4.3.0 server, and that the XCopyPlane error is a well-known error
+  resulting from an XTEST/Xinerama interaction when the request crosses
+  a screen boundary.  The XDraw* errors are resolved when the tests are
+  run individually and they do not cross a screen boundary.  We will
+  investigate these errors further to determine their cause.
+
+
+  BB..44..33..55..  XXddmmxx wwiitthh XXTTEESSTT,, wwiitthh XXiinneerraammaa,, wwiitthh GGLLXX
+
+  With GLX enabled, using the XTEST extension, the following errors were
+  reported from Xdmx (these results are from early during the Phase IV
+  development, but were confirmed with a late Phase IV snapshot):
+
+  XListPixmapFormats: Test 1
+  XChangeKeyboardControl: Tests 9, 10
+  XRebindKeysym: Test 1
+
+  XAllowEvents: Tests 20, 21, 24
+  XGrabButton: Tests 5, 9-12, 14, 16, 19, 21-25
+  XGrabKey: Test 8
+  XSetPointerMapping: Test 3
+  XUngrabButton: Test 4
+
+  XClearArea: Test 8
+  XCopyArea: Tests 4, 5, 11, 14, 17, 23, 25, 27, 30
+  XCopyPlane: Tests 6, 7, 10, 19, 22, 31
+  XDrawArcs: Tests 89, 100, 102
+  XDrawLine: Test 67
+  XDrawSegments: Test 68
+
+
+  Note that the first two sets of errors are the same as for the XFree86
+  4.3.0 server, and that the third set has different failures than when
+  Xdmx does not include GLX support.  Since the GLX extension adds new
+  visuals to support GLX's visual configs and the X Test Suite runs
+  tests over the entire set of visuals, additional rendering tests were
+  run and presumably more of them crossed a screen boundary.  This con-
+  clusion is supported by the fact that nearly all of the rendering
+  errors reported are resolved when the tests are run individually and
+  they do no cross a screen boundary.
+
+
+  Further, when hardware rendering is disabled on the back-end displays,
+  many of the errors in the third set are eliminated, leaving only:
+
+  XClearArea: Test 8
+  XCopyArea: Test 4, 5, 11, 14, 17, 23, 25, 27, 30
+  XCopyPlane: Test 6, 7, 10, 19, 22, 31
+
+
+
+  BB..44..33..66..  CCoonncclluussiioonn
+
+  We conclude that all of the X Test Suite errors reported for Xdmx are
+  the result of errors in the back-end X server or the Xinerama
+  implementation.  Further, all of these errors that can be reasonably
+  fixed at the Xdmx layer have been.  (Where appropriate, we have
+  submitted patches to the XFree86 and Xinerama upstream maintainers.)
+
+
+  BB..44..44..  DDyynnaammiicc RReeccoonnffiigguurraattiioonn
+
+  During this development phase, dynamic reconfiguration support was
+  added to DMX.  This support allows an application to change the
+  position and offset of a back-end server's screen.  For example, if
+  the application would like to shift a screen slightly to the left, it
+  could query Xdmx for the screen's <x,y> position and then dynamically
+  reconfigure that screen to be at position <x+10,y>.  When a screen is
+  dynamically reconfigured, input handling and a screen's root window
+  dimensions are adjusted as needed.  These adjustments are transparent
+  to the user.
+
+
+  BB..44..44..11..  DDyynnaammiicc rreeccoonnffiigguurraattiioonn eexxtteennssiioonn
+
+  The application interface to DMX's dynamic reconfiguration is through
+  a function in the DMX extension library:
+
+  Bool DMXReconfigureScreen(Display *dpy, int screen, int x, int y)
+
+
+  where _d_p_y is DMX server's display, _s_c_r_e_e_n is the number of the screen
+  to be reconfigured, and _x and _y are the new upper, left-hand coordi-
+  nates of the screen to be reconfigured.
+
+
+  The coordinates are not limited other than as required by the X
+  protocol, which limits all coordinates to a signed 16 bit number.  In
+  addition, all coordinates within a screen must also be legal values.
+  Therefore, setting a screen's upper, left-hand coordinates such that
+  the right or bottom edges of the screen is greater than 32,767 is
+  illegal.
+
+
+  BB..44..44..22..  BBoouunnddiinngg bbooxx
+
+  When the Xdmx server is started, a bounding box is calculated from the
+  screens' layout given either on the command line or in the
+  configuration file.  This bounding box is currently fixed for the
+  lifetime of the Xdmx server.
+
+
+  While it is possible to move a screen outside of the bounding box, it
+  is currently not possible to change the dimensions of the bounding
+  box.  For example, it is possible to specify coordinates of
+  <-100,-100> for the upper, left-hand corner of the bounding box, which
+  was previously at coordinates <0,0>.  As expected, the screen is moved
+  down and to the right; however, since the bounding box is fixed, the
+  left side and upper portions of the screen exposed by the
+  reconfiguration are no longer accessible on that screen.  Those
+  inaccessible regions are filled with black.
+
+
+  This fixed bounding box limitation will be addressed in a future
+  development phase.
+
+
+  BB..44..44..33..  SSaammppllee aapppplliiccaattiioonnss
+
+  An example of where this extension is useful is in setting up a video
+  wall.  It is not always possible to get everything perfectly aligned,
+  and sometimes the positions are changed (e.g., someone might bump into
+  a projector).  Instead of physically moving projectors or monitors, it
+  is now possible to adjust the positions of the back-end server's
+  screens using the dynamic reconfiguration support in DMX.
+
+
+  Other applications, such as automatic setup and calibration tools, can
+  make use of dynamic reconfiguration to correct for projector alignment
+  problems, as long as the projectors are still arranged rectilinearly.
+  Horizontal and vertical keystone correction could be applied to
+  projectors to correct for non-rectilinear alignment problems; however,
+  this must be done external to Xdmx.
+
+
+  A sample test program is included in the DMX server's examples
+  directory to demonstrate the interface and how an application might
+  use dynamic reconfiguration.  See dmxreconfig.c for details.
+
+
+  BB..44..44..44..  AAddddiittiioonnaall nnootteess
+
+  In the original development plan, Phase IV was primarily devoted to
+  adding OpenGL support to DMX; however, SGI became interested in the
+  DMX project and developed code to support OpenGL/GLX.  This code was
+  later donated to the DMX project and integrated into the DMX code
+  base, which freed the DMX developers to concentrate on dynamic
+  reconfiguration (as described above).
+
+
+  BB..44..55..  DDooxxyyggeenn ddooccuummeennttaattiioonn
+
+  Doxygen is an open-source (GPL) documentation system for generating
+  browseable documentation from stylized comments in the source code.
+  We have placed all of the Xdmx server and DMX protocol source code
+  files under Doxygen so that comprehensive documentation for the Xdmx
+  source code is available in an easily browseable format.
+
+
+  BB..44..66..  VVaallggrriinndd
+
+  Valgrind, an open-source (GPL) memory debugger for Linux, was used to
+  search for memory management errors.  Several memory leaks were
+  detected and repaired.  The following errors were not addressed:
+
+  1. When the X11 transport layer sends a reply to the client, only
+     those fields that are required by the protocol are filled in --
+     unused fields are left as uninitialized memory and are therefore
+     noted by valgrind.  These instances are not errors and were not
+     repaired.
+
+  2. At each server generation, glxInitVisuals allocates memory that is
+     never freed.  The amount of memory lost each generation
+     approximately equal to 128 bytes for each back-end visual.  Because
+     the code involved is automatically generated, this bug has not been
+     fixed and will be referred to SGI.
+
+  3. At each server generation, dmxRealizeFont calls XLoadQueryFont,
+     which allocates a font structure that is not freed.
+     dmxUnrealizeFont can free the font structure for the first screen,
+     but cannot free it for the other screens since they are already
+     closed by the time dmxUnrealizeFont could free them.  The amount of
+     memory lost each generation is approximately equal to 80 bytes per
+     font per back-end.  When this bug is fixed in the the X server's
+     device-independent (dix) code, DMX will be able to properly free
+     the memory allocated by XLoadQueryFont.
+
+
+  BB..44..77..  RRAATTSS
+
+  RATS (Rough Auditing Tool for Security) is an open-source (GPL)
+  security analysis tool that scans source code for common security-
+  related programming errors (e.g., buffer overflows and TOCTOU races).
+  RATS was used to audit all of the code in the hw/dmx directory and all
+  "High" notations were checked manually.  The code was either re-
+  written to eliminate the warning, or a comment containing "RATS" was
+  inserted on the line to indicate that a human had checked the code.
+  Unrepaired warnings are as follows:
+
+  1. Fixed-size buffers are used in many areas, but code has been added
+     to protect against buffer overflows (e.g., XmuSnprint).  The only
+     instances that have not yet been fixed are in config/xdmxconfig.c
+     (which is not part of the Xdmx server) and input/usb-common.c.
+
+  2. vprintf and vfprintf are used in the logging routines.  In general,
+     all uses of these functions (e.g., dmxLog) provide a constant
+     format string from a trusted source, so the use is relatively
+     benign.
+
+  3. glxProxy/glxscreens.c uses getenv and strcat.  The use of these
+     functions is safe and will remain safe as long as ExtensionsString
+     is longer then GLXServerExtensions (ensuring this may not be ovious
+     to the casual programmer, but this is in automatically generated
+     code, so we hope that the generator enforces this constraint).
+
+
+