Checked in the following released items:

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

1 files changed, 1427 insertions, 0 deletions

diff --git a/xorg-server/hw/xfree86/xaa/XAA.HOWTO b/xorg-server/hw/xfree86/xaa/XAA.HOWTO
new file mode 100644
index 000000000..cbd71c138
--- /dev/null
+++ b/xorg-server/hw/xfree86/xaa/XAA.HOWTO
@@ -0,0 +1,1427 @@
+
+
+                          XAA.HOWTO
+
+  This file describes how to add basic XAA support to a chipset driver.
+
+0)  What is XAA
+1)  XAA Initialization and Shutdown
+2)  The Primitives
+  2.0  Generic Flags
+  2.1  Screen to Screen Copies
+  2.2  Solid Fills
+  2.3  Solid Lines
+  2.4  Dashed Lines
+  2.5  Color Expand Fills
+    2.5.1 Screen to Screen Color Expansion
+    2.5.2 CPU to Screen Color Expansion
+      2.5.2.1 The Direct Method
+      2.5.2.2 The Indirect Method
+  2.6  8x8 Mono Pattern Fills
+  2.7  8x8 Color Pattern Fills
+  2.8  Image Writes
+    2.8.1 The Direct Method
+    2.8.2 The Indirect Method
+  2.9 Clipping
+3)  The Pixmap Cache
+4)  Offscreen Pixmaps
+
+/********************************************************************/
+
+0) WHAT IS XAA
+	
+   XAA (the XFree86 Acceleration Architecture) is a device dependent
+layer that encapsulates the unaccelerated framebuffer rendering layer,
+intercepting rendering commands sent to it from higher levels of the
+server.  For rendering tasks where hardware acceleration is not 
+possible, XAA allows the requests to proceed to the software rendering
+code.  Otherwise, XAA breaks the sometimes complicated X primitives
+into simpler primitives more suitable for hardware acceleration and
+will use accelerated functions exported by the chipset driver to 
+render these.
+
+   XAA provides a simple, easy to use driver interface that allows
+the driver to communicate its acceleration capabilities and restrictions
+back to XAA.  XAA will use the information provided by the driver
+to determine whether or not acceleration will be possible for a
+particular X primitive.
+
+
+
+1) XAA INITIALIZATION AND SHUTDOWN
+
+   All relevant prototypes and defines are in xaa.h.
+
+   To Initialize the XAA layer, the driver should allocate an XAAInfoRec
+via XAACreateInfoRec(), fill it out as described in this document
+and pass it to XAAInit().  XAAInit() must be called _after_ the 
+framebuffer initialization (usually cfb?ScreenInit or similar) since 
+it is "wrapping" that layer.  XAAInit() should be called _before_ the 
+cursor initialization (usually miDCInitialize) since the cursor
+layer needs to "wrap" all the rendering code including XAA.
+
+   When shutting down, the driver should free the XAAInfoRec
+structure in its CloseScreen function via XAADestroyInfoRec().
+The prototypes for the functions mentioned above are as follows:
+
+   XAAInfoRecPtr XAACreateInfoRec(void);
+   Bool XAAInit(ScreenPtr, XAAInfoRecPtr);
+   void XAADestroyInfoRec(XAAInfoRec);
+
+   The driver informs XAA of it's acceleration capablities by
+filling out an XAAInfoRec structure and passing it to XAAInit().
+The XAAInfoRec structure contains many fields, most of which are
+function pointers and flags.  Each primitive will typically have
+two functions and a set of flags associated with it, but it may
+have more.  These two functions are the "SetupFor" and "Subsequent" 
+functions.  The "SetupFor" function tells the driver that the 
+hardware should be initialized for a particular type of graphics 
+operation.  After the "SetupFor" function, one or more calls to the 
+"Subsequent" function will be made to indicate that an instance
+of the particular primitive should be rendered by the hardware.
+The details of each instance (width, height, etc...) are given
+with each "Subsequent" function.   The set of flags associated
+with each primitive lets the driver tell XAA what its hardware
+limitations are (eg. It doesn't support a planemask, it can only
+do one of the raster-ops, etc...).
+
+  Of the XAAInfoRec fields, one is required.  This is the
+Sync function.  XAA initialization will fail if this function
+is not provided.
+
+void Sync(ScrnInfoPtr pScrn)			/* Required */
+
+   Sync will be called when XAA needs to be certain that all
+   graphics coprocessor operations are finished, such as when
+   the framebuffer must be written to or read from directly
+   and it must be certain that the accelerator will not be
+   overwriting the area of interest.
+
+   One needs to make certain that the Sync function not only
+   waits for the accelerator fifo to empty, but that it waits for
+   the rendering of that last operation to complete.
+
+   It is guaranteed that no direct framebuffer access will
+   occur after a "SetupFor" or "Subsequent" function without
+   the Sync function being called first.
+
+
+
+2)  THE PRIMITIVES
+
+2.0  Generic Flags
+
+  Each primitive type has a set of flags associated with it which
+allow the driver to tell XAA what the hardware limitations are.
+The common ones are as follows:
+
+/* Foreground, Background, rop and planemask restrictions */
+
+   GXCOPY_ONLY
+
+     This indicates that the accelerator only supports GXcopy
+     for the particular primitive.
+
+   ROP_NEEDS_SOURCE
+
+     This indicates that the accelerator doesn't supports a
+     particular primitive with rops that don't involve the source.
+     These rops are GXclear, GXnoop, GXinvert and GXset. If neither
+     this flag nor GXCOPY_ONLY is defined, it is assumed that the
+     accelerator supports all 16 raster operations (rops) for that
+     primitive.
+
+   NO_PLANEMASK
+
+     This indicates that the accelerator does not support a hardware
+     write planemask for the particular primitive.
+
+   RGB_EQUAL
+
+     This indicates that the particular primitive requires the red, 
+     green and blue bytes of the foreground color (and background color,
+     if applicable) to be equal. This is useful for 24bpp when a graphics
+     coprocessor is used in 8bpp mode, which is not uncommon in older
+     hardware since some have no support for or only limited support for 
+     acceleration at 24bpp. This way, many operations will be accelerated 
+     for the common case of "grayscale" colors.  This flag should only
+     be used in 24bpp.
+
+  In addition to the common ones listed above which are possible for
+nearly all primitives, each primitive may have its own flags specific
+to that primitive.  If such flags exist they are documented in the
+descriptions of those primitives below.
+ 
+
+
+
+2.1  Screen to Screen Copies
+
+   The SetupFor and Subsequent ScreenToScreenCopy functions provide
+   an interface for copying rectangular areas from video memory to
+   video memory.  To accelerate this primitive the driver should
+   provide both the SetupFor and Subsequent functions and indicate
+   the hardware restrictions via the ScreenToScreenCopyFlags.  The
+   NO_PLANEMASK, GXCOPY_ONLY and ROP_NEEDS_SOURCE flags as described
+   in Section 2.0 are valid as well as the following:
+
+    NO_TRANSPARENCY
+     
+      This indicates that the accelerator does not support skipping
+      of color keyed pixels when copying from the source to the destination.
+
+    TRANSPARENCY_GXCOPY_ONLY
+
+      This indicates that the accelerator supports skipping of color keyed
+      pixels only when the rop is GXcopy.
+
+    ONLY_LEFT_TO_RIGHT_BITBLT
+
+      This indicates that the hardware only accepts blitting when the
+      x direction is positive.
+
+    ONLY_TWO_BITBLT_DIRECTIONS
+
+      This indicates that the hardware can only cope with blitting when
+      the direction of x is the same as the direction in y.
+
+
+void SetupForScreenToScreenCopy( ScrnInfoPtr pScrn,
+			int xdir, int ydir,
+			int rop,
+			unsigned int planemask,
+			int trans_color )
+
+    When this is called, SubsequentScreenToScreenCopy will be called
+    one or more times directly after.  If ydir is 1, then the accelerator
+    should copy starting from the top (minimum y) of the source and
+    proceed downward.  If ydir is -1, then the accelerator should copy
+    starting from the bottom of the source (maximum y) and proceed
+    upward.  If xdir is 1, then the accelerator should copy each
+    y scanline starting from the leftmost pixel of the source.  If
+    xdir is -1, it should start from the rightmost pixel.  
+       If trans_color is not -1 then trans_color indicates that the
+    accelerator should not copy pixels with the color trans_color
+    from the source to the destination, but should skip them. 
+    Trans_color is always -1 if the NO_TRANSPARENCY flag is set.
+ 
+
+void SubsequentScreenToScreenCopy(ScrnInfoPtr pScrn,
+			int x1, int y1,
+			int x2, int y2,
+			int width, int height)
+
+    Copy a rectangle "width" x "height" from the source (x1,y1) to the 
+    destination (x2,y2) using the parameters passed by the last
+    SetupForScreenToScreenCopy call. (x1,y1) and (x2,y2) always denote 
+    the upper left hand corners of the source and destination regardless 
+    of which xdir and ydir values are given by SetupForScreenToScreenCopy.  
+
+
+
+2.2 Solid Fills
+
+   The SetupFor and Subsequent SolidFill(Rect/Trap) functions provide
+   an interface for filling rectangular areas of the screen with a
+   foreground color.  To accelerate this primitive the driver should
+   provide both the SetupForSolidFill and SubsequentSolidFillRect 
+   functions and indicate the hardware restrictions via the SolidFillFlags.
+   The driver may optionally provide a SubsequentSolidFillTrap if
+   it is capable of rendering the primitive correctly.  
+   The GXCOPY_ONLY, ROP_NEEDS_SOURCE, NO_PLANEMASK and RGB_EQUAL flags
+   as described in Section 2.0 are valid.
+
+  
+void SetupForSolidFill(ScrnInfoPtr pScrn, 
+                       int color, int rop, unsigned int planemask)
+
+    SetupForSolidFill indicates that any combination of the following 
+    may follow it.
+
+	SubsequentSolidFillRect
+	SubsequentSolidFillTrap
+
+
+ 
+void SubsequentSolidFillRect(ScrnInfoPtr pScrn, int x, int y, int w, int h)
+
+     Fill a rectangle of dimensions "w" by "h" with origin at (x,y) 
+     using the color, rop and planemask given by the last 
+     SetupForSolidFill call.
+
+void SubsequentSolidFillTrap(ScrnInfoPtr pScrn, int y, int h, 
+	int left, int dxL, int dyL, int eL,
+	int right, int dxR, int dyR, int eR)
+
+     These parameters describe a trapezoid via a version of
+     Bresenham's parameters. "y" is the top line. "h" is the
+     number of spans to be filled in the positive Y direction.
+     "left" and "right" indicate the starting X values of the
+     left and right edges.  dy/dx describes the edge slope.
+     These are not the deltas between the beginning and ending
+     points on an edge.  They merely describe the slope. "e" is
+     the initial error term.  It's the relationships between dx,
+     dy and e that define the edge.
+	If your engine does not do bresenham trapezoids or does
+     not allow the programmer to specify the error term then
+     you are not expected to be able to accelerate them.
+
+
+2.3  Solid Lines
+
+    XAA provides an interface for drawing thin lines.  In order to
+    draw X lines correctly a high degree of accuracy is required.
+    This usually limits line acceleration to hardware which has a
+    Bresenham line engine, though depending on the algorithm used,
+    other line engines may come close if they accept 16 bit line 
+    deltas.  XAA has both a Bresenham line interface and a two-point
+    line interface for drawing lines of arbitrary orientation.  
+    Additionally there is a SubsequentSolidHorVertLine which will
+    be used for all horizontal and vertical lines.  Horizontal and
+    vertical lines are handled separately since hardware that doesn't
+    have a line engine (or has one that is unusable due to precision
+    problems) can usually draw these lines by some other method such
+    as drawing them as thin rectangles.  Even for hardware that can
+    draw arbitrary lines via the Bresenham or two-point interfaces,
+    the SubsequentSolidHorVertLine is used for horizontal and vertical
+    lines since most hardware is able to render the horizontal lines
+    and sometimes the vertical lines faster by other methods (Hint:
+    try rendering horizontal lines as flattened rectangles).  If you have 
+    not provided a SubsequentSolidHorVertLine but you have provided 
+    Bresenham or two-point lines, a SubsequentSolidHorVertLine function 
+    will be supplied for you.
+
+    The flags field associated with Solid Lines is SolidLineFlags and 
+    the GXCOPY_ONLY, ROP_NEEDS_SOURCE, NO_PLANEMASK and RGB_EQUAL flags as
+    described in Section 2.0 are valid restrictions.  
+
+    Some line engines have line biases hardcoded to comply with
+    Microsoft line biasing rules.  A tell-tale sign of this is the
+    hardware lines not matching the software lines in the zeroth and
+    fourth octants.  The driver can set the flag:
+	
+	MICROSOFT_ZERO_LINE_BIAS
+
+    in the AccelInfoRec.Flags field to adjust the software lines to
+    match the hardware lines.   This is in the generic flags field
+    rather than the SolidLineFlags since this flag applies to all
+    software zero-width lines on the screen and not just the solid ones.
+
+
+void SetupForSolidLine(ScrnInfoPtr pScrn, 
+                       int color, int rop, unsigned int planemask)
+
+    SetupForSolidLine indicates that any combination of the following 
+    may follow it.
+
+	SubsequentSolidBresenhamLine
+	SubsequentSolidTwoPointLine
+        SubsequentSolidHorVertLine 	
+
+
+void SubsequentSolidHorVertLine( ScrnInfoPtr pScrn,
+        			int x, int y, int len, int dir )
+
+    All vertical and horizontal solid thin lines are rendered with
+    this function.  The line starts at coordinate (x,y) and extends
+    "len" pixels inclusive.  In the direction indicated by "dir."
+    The direction is either DEGREES_O or DEGREES_270.  That is, it
+    always extends to the right or down.
+
+
+
+void SubsequentSolidTwoPointLine(ScrnInfoPtr pScrn,
+        	int x1, int y1, int x2, int y2, int flags)
+
+    Draw a line from (x1,y1) to (x2,y2).  If the flags field contains
+    the flag OMIT_LAST, the last pixel should not be drawn.  Otherwise,
+    the pixel at (x2,y2) should be drawn.
+
+    If you use the TwoPoint line interface there is a good possibility
+    that your line engine has hard-coded line biases that do not match
+    the default X zero-width lines.  If so, you may need to set the
+    MICROSOFT_ZERO_LINE_BIAS flag described above.  Note that since
+    any vertex in the 16-bit signed coordinate system is valid, your
+    line engine is expected to handle 16-bit values if you have hardware
+    line clipping enabled.  If your engine cannot handle 16-bit values,
+    you should not use hardware line clipping.
+
+
+void SubsequentSolidBresenhamLine(ScrnInfoPtr pScrn,
+        int x, int y, int major, int minor, int err, int len, int octant)
+
+    "X" and "y" are the starting point of the line.  "Major" and "minor" 
+    are the major and minor step constants.  "Err" is the initial error
+    term.  "Len" is the number of pixels to be drawn (inclusive). "Octant"
+    can be any combination of the following flags OR'd together:
+
+      Y_MAJOR		Y is the major axis (X otherwise)
+      X_DECREASING	The line is drawn from right to left
+      Y_DECREASING	The line is drawn from bottom to top
+	  
+    The major, minor and err terms are the "raw" Bresenham parameters
+    consistent with a line engine that does:
+
+	e = err;
+	while(len--) {
+	   DRAW_POINT(x,y);
+	   e += minor;
+	   if(e >= 0) {
+		e -= major;
+		TAKE_ONE_STEP_ALONG_MINOR_AXIS;
+	   }
+	   TAKE_ONE_STEP_ALONG_MAJOR_AXIS;
+	}
+
+    IBM 8514 style Bresenham line interfaces require their parameters
+    modified in the following way:
+
+	Axial = minor;
+	Diagonal = minor - major;
+	Error = minor + err;
+
+SolidBresenhamLineErrorTermBits
+
+    This field allows the driver to tell XAA how many bits large its
+    Bresenham parameter registers are.  Many engines have registers that
+    only accept 12 or 13 bit Bresenham parameters, and the parameters
+    for clipped lines may overflow these if they are not scaled down.
+    If this field is not set, XAA will assume the engine can accomodate
+    16 bit parameters, otherwise, it will scale the parameters to the
+    size specified.
+
+
+2.4  Dashed Lines
+
+    The same degree of accuracy required by the solid lines is required
+    for drawing dashed lines as well.  The dash pattern itself is a
+    buffer of binary data where ones are expanded into the foreground
+    color and zeros either correspond to the background color or
+    indicate transparency depending on whether or not DoubleDash or
+    OnOffDashes are being drawn.  
+
+    The flags field associated with dashed Lines is DashedLineFlags and 
+    the GXCOPY_ONLY, ROP_NEEDS_SOURCE, NO_PLANEMASK and RGB_EQUAL flags as
+    described in Section 2.0 are valid restrictions.  Additionally, the
+    following flags are valid:
+
+      NO_TRANSPARENCY
+
+	This indicates that the driver cannot support dashed lines
+	with transparent backgrounds (OnOffDashes).
+
+      TRANSPARENCY_ONLY
+
+	This indicates that the driver cannot support dashes with
+	both a foreground and background color (DoubleDashes).
+
+      LINE_PATTERN_POWER_OF_2_ONLY
+
+	This indicates that only patterns with a power of 2 length
+	can be accelerated.
+
+      LINE_PATTERN_LSBFIRST_MSBJUSTIFIED
+      LINE_PATTERN_LSBFIRST_LSBJUSTIFIED
+      LINE_PATTERN_MSBFIRST_MSBJUSTIFIED
+      LINE_PATTERN_MSBFIRST_LSBJUSTIFIED
+
+	These describe how the line pattern should be packed.
+	The pattern buffer is DWORD padded.  LSBFIRST indicates
+	that the pattern runs from the LSB end to the MSB end.
+	MSBFIRST indicates that the pattern runs from the MSB end
+	to the LSB end.  When the pattern does not completely fill
+	the DWORD padded buffer, the pattern will be justified 
+	towards the MSB or LSB end based on the flags above.
+
+
+    The following field indicates the maximum length dash pattern that
+    should be accelerated.
+
+	int DashPatternMaxLength
+
+
+void SetupForDashedLine(ScrnInfoPtr pScrn,
+		int fg, int bg, int rop, unsigned int planemask,
+        	int length, unsigned char *pattern)
+
+    
+    SetupForDashedLine indicates that any combination of the following 
+    may follow it.
+
+	SubsequentDashedBresenhamLine
+	SubsequentDashedTwoPointLine
+
+    If "bg" is -1, then the background (pixels corresponding to clear
+    bits in the pattern) should remain unmodified. "Bg" indicates the
+    background color otherwise.  "Length" indicates the length of
+    the pattern in bits and "pattern" points to the DWORD padded buffer
+    holding the pattern which has been packed according to the flags
+    set above.  
+
+    
+void SubsequentDashedTwoPointLine( ScrnInfoPtr pScrn,
+        int x1, int y1, int x2, int y2, int flags, int phase)
+
+void SubsequentDashedBresenhamLine(ScrnInfoPtr pScrn,
+        int x1, int y1, int major, int minor, int err, int len, int octant,
+        int phase)
+  
+    These are the same as the SubsequentSolidTwoPointLine and
+    SubsequentBresenhamLine functions except for the addition
+    of the "phase" field which indicates the offset into the dash 
+    pattern that the pixel at (x1,y1) corresponds to.
+
+    As with the SubsequentBresenhamLine, there is an
+ 
+	int DashedBresenhamLineErrorTermBits 
+   
+    field which indicates the size of the error term registers
+    used with dashed lines.  This is usually the same value as
+    the field for the solid lines (because it's usually the same
+    register).
+       
+      
+
+2.5   Color Expansion Fills
+
+    When filling a color expansion rectangle, the accelerator
+    paints each pixel depending on whether or not a bit in a
+    corresponding bitmap is set or clear. Opaque expansions are 
+    when a set bit corresponds to the foreground color and a clear 
+    bit corresponds to the background color.  A transparent expansion
+    is when a set bit corresponds to the foreground color and a
+    clear bit indicates that the pixel should remain unmodified.
+   
+    The graphics accelerator usually has access to the source 
+    bitmap in one of two ways: 1) the bitmap data is sent serially
+    to the accelerator by the CPU through some memory mapped aperture
+    or 2) the accelerator reads the source bitmap out of offscreen
+    video memory.  Some types of primitives are better suited towards 
+    one method or the other.  Type 2 is useful for reusable patterns
+    such as stipples which can be cached in offscreen memory.  The
+    aperature method can be used for stippling but the CPU must pass
+    the data across the bus each time a stippled fill is to be performed.  
+    For expanding 1bpp client pixmaps or text strings to the screen,
+    the aperature method is usually superior because the intermediate
+    copy in offscreen memory needed by the second method would only be 
+    used once.  Unfortunately, many accelerators can only do one of these
+    methods and not both.  
+
+    XAA provides both ScreenToScreen and CPUToScreen color expansion 
+    interfaces for doing color expansion fills.  The ScreenToScreen
+    functions can only be used with hardware that supports reading
+    of source bitmaps from offscreen video memory, and these are only
+    used for cacheable patterns such as stipples.  There are two
+    variants of the CPUToScreen routines - a direct method intended
+    for hardware that has a transfer aperature, and an indirect method
+    intended for hardware without transfer aperatures or hardware
+    with unusual transfer requirements.  Hardware that can only expand
+    bitmaps from video memory should supply ScreenToScreen routines
+    but also ScanlineCPUToScreen (indirect) routines to optimize transfers 
+    of non-cacheable data.  Hardware that can only accept source bitmaps
+    through an aperature should supply CPUToScreen (or ScanlineCPUToScreen) 
+    routines. Hardware that can do both should provide both ScreenToScreen 
+    and CPUToScreen routines.
+
+    For both ScreenToScreen and CPUToScreen interfaces, the GXCOPY_ONLY,
+    ROP_NEEDS_SOURCE, NO_PLANEMASK and RGB_EQUAL flags described in
+    Section 2.0 are valid as well as the following:
+
+    /* bit order requirements (one of these must be set) */
+   
+    BIT_ORDER_IN_BYTE_LSBFIRST
+
+      This indicates that least significant bit in each byte of the source
+      data corresponds to the leftmost of that block of 8 pixels.  This
+      is the prefered format.
+
+    BIT_ORDER_IN_BYTE_MSBFIRST    
+
+      This indicates that most significant bit in each byte of the source
+      data corresponds to the leftmost of that block of 8 pixels.
+
+    /* transparency restrictions */
+
+    NO_TRANSPARENCY
+
+      This indicates that the accelerator cannot do a transparent expansion.
+
+    TRANSPARENCY_ONLY
+
+      This indicates that the accelerator cannot do an opaque expansion.
+      In cases where where the background needs to be filled, XAA will
+      render the primitive in two passes when using the CPUToScreen
+      interface, but will not do so with the ScreenToScreen interface 
+      since that would require caching of two patterns.  Some 
+      ScreenToScreen hardware may be able to render two passes at the
+      driver level and remove the TRANSPARENCY_ONLY restriction if
+      it can render pixels corresponding to the zero bits.
+
+
+
+2.5.1  Screen To Screen Color Expansion
+
+    The ScreenToScreenColorExpandFill routines provide an interface
+    for doing expansion blits from source patterns stored in offscreen
+    video memory.
+
+    void SetupForScreenToScreenColorExpandFill (ScrnInfoPtr pScrn,
+        			int fg, int bg, 
+				int rop, unsigned int planemask)
+
+
+    Ones in the source bitmap will correspond to the fg color.
+    Zeros in the source bitmap will correspond to the bg color
+    unless bg = -1.  In that case the pixels corresponding to the
+    zeros in the bitmap shall be left unmodified by the accelerator.
+
+    For hardware that doesn't allow an easy implementation of skipleft, the
+    driver can replace CacheMonoStipple function with one that stores multiple
+    rotated copies of the stipple and select between them. In this case the
+    driver should set CacheColorExpandDensity to tell XAA how many copies of
+    the pattern are stored in the width of a cache slot. For instance if the
+    hardware can specify the starting address in bytes, then 8 rotated copies
+    of the stipple are needed and CacheColorExpandDensity should be set to 8.
+
+    void SubsequentScreenToScreenColorExpandFill( ScrnInfoPtr pScrn,
+				int x, int y, int w, int h,
+				int srcx, int srcy, int offset )
+
+   
+    Fill a rectangle "w" x "h" at location (x,y).  The source pitch
+    between scanlines is the framebuffer pitch (pScrn->displayWidth
+    pixels) and srcx and srcy indicate the start of the source pattern 
+    in units of framebuffer pixels. "Offset" indicates the bit offset
+    into the pattern that corresponds to the pixel being painted at
+    "x" on the screen.  Some hardware accepts source coordinates in
+    units of bits which makes implementation of the offset trivial.
+    In that case, the bit address of the source bit corresponding to
+    the pixel painted at (x,y) would be:
+	
+     (srcy * pScrn->displayWidth + srcx) * pScrn->bitsPerPixel + offset
+
+    It should be noted that the offset assumes LSBFIRST hardware.  
+    For MSBFIRST hardware, the driver may need to implement the 
+    offset by bliting only from byte boundaries and hardware clipping.
+
+
+
+2.5.2  CPU To Screen Color Expansion
+
+
+    The CPUToScreenColorExpandFill routines provide an interface for 
+    doing expansion blits from source patterns stored in system memory.
+    There are two varieties of this primitive, a CPUToScreenColorExpandFill
+    and a ScanlineCPUToScreenColorExpandFill.  With the 
+    CPUToScreenColorExpandFill method, the source data is sent serially
+    through a memory mapped aperature.  With the Scanline version, the
+    data is rendered scanline at a time into intermediate buffers with
+    a call to SubsequentColorExpandScanline following each scanline.
+
+    These two methods have separate flags fields, the
+    CPUToScreenColorExpandFillFlags and ScanlineCPUToScreenColorExpandFillFlags
+    respectively.  Flags specific to one method or the other are described 
+    in sections 2.5.2.1 and 2.5.2.2 but for both cases the bit order and
+    transparency restrictions listed at the beginning of section 2.5 are 
+    valid as well as the following:
+    
+    /* clipping  (optional) */
+    
+    LEFT_EDGE_CLIPPING
+ 
+      This indicates that the accelerator supports omission of up to
+      31 pixels on the left edge of the rectangle to be filled.  This
+      is beneficial since it allows transfer of the source bitmap to
+      always occur from DWORD boundaries. 
+
+    LEFT_EDGE_CLIPPING_NEGATIVE_X
+
+      This flag indicates that the accelerator can render color expansion
+      rectangles even if the value of x origin is negative (off of
+      the screen on the left edge).
+
+    /* misc */
+
+    TRIPLE_BITS_24BPP
+
+      When enabled (must be in 24bpp mode), color expansion functions
+      are expected to require three times the amount of bits to be
+      transferred so that 24bpp grayscale colors can be used with color
+      expansion in 8bpp coprocessor mode. Each bit is expanded to 3
+      bits when writing the monochrome data.
+
+
+ 2.5.1 The Direct Method 
+
+
+    Using the direct method of color expansion XAA will send all
+    bitmap data to the accelerator serially through an memory mapped
+    transfer window defined by the following two fields:
+
+      unsigned char *ColorExpandBase
+
+        This indicates the memory address of the beginning of the aperture.
+
+      int ColorExpandRange
+
+        This indicates the size in bytes of the aperture.
+
+    The driver should specify how the transfered data should be padded.
+    There are options for both the padding of each Y scanline and for the
+    total transfer to the aperature.
+    One of the following two flags must be set:
+
+      CPU_TRANSFER_PAD_DWORD
+
+        This indicates that the total transfer (sum of all scanlines) sent
+        to the aperature must be DWORD padded.  This is the default behavior.
+
+      CPU_TRANSFER_PAD_QWORD 
+
+	This indicates that the total transfer (sum of all scanlines) sent
+	to the aperature must be QWORD padded.  With this set, XAA will send
+        an extra DWORD to the aperature when needed to ensure that only
+        an even number of DWORDs are sent.
+
+    And then there are the flags for padding of each scanline:
+
+      SCANLINE_PAD_DWORD
+
+	This indicates that each Y scanline should be DWORD padded.
+        This is the only option available and is the default.
+
+    Finally, there is the CPU_TRANSFER_BASE_FIXED flag which indicates
+    that the aperture is a single register rather than a range of
+    registers, and XAA should write all of the data to the first DWORD.
+    If the ColorExpandRange is not large enough to accomodate scanlines
+    the width of the screen, this option will be forced. That is, the
+    ColorExpandRange must be:
+
+        ((virtualX + 31)/32) * 4   bytes or more.
+
+        ((virtualX + 62)/32 * 4) if LEFT_EDGE_CLIPPING_NEGATIVE_X is set.
+  
+    If the TRIPLE_BITS_24BPP flag is set, the required area should be 
+    multiplied by three.
+     
+    
+void SetupForCPUToScreenColorExpandFill(ScrnInfoPtr pScrn,
+        		int fg, int bg,
+			int rop,
+			unsigned int planemask)
+
+  
+ 
+     Ones in the source bitmap will correspond to the fg color.
+     Zeros in the source bitmap will correspond to the bg color
+     unless bg = -1.  In that case the pixels corresponding to the
+     zeros in the bitmap shall be left unmodified by the accelerator.
+
+
+void SubsequentCPUToScreenColorExpandFill(ScrnInfoPtr pScrn,
+			int x, int y, int w, int h,
+			int skipleft )
+
+     When this function is called, the accelerator should be setup
+     to fill a rectangle of dimension "w" by "h" with origin at (x,y)
+     in the fill style prescribed by the last call to 
+     SetupForCPUToScreenColorExpandFill.  XAA will pass the data to 
+     the aperture immediately after this function is called.  If the 
+     skipleft is non-zero (and LEFT_EDGE_CLIPPING has been enabled), then 
+     the accelerator _should_not_ render skipleft pixels on the leftmost
+     edge of the rectangle.  Some engines have an alignment feature
+     like this built in, some others can do this using a clipping
+     window.
+
+     It can be arranged for XAA to call Sync() after it is through 
+     calling the Subsequent function by setting SYNC_AFTER_COLOR_EXPAND 
+     in the  CPUToScreenColorExpandFillFlags.  This can provide the driver 
+     with an oportunity to reset a clipping window if needed.
+
+    
+2.5.2  The Indirect Method 
+
+     Using the indirect method, XAA will render the bitmap data scanline
+     at a time to one or more buffers.  These buffers may be memory
+     mapped apertures or just intermediate storage.
+
+     int NumScanlineColorExpandBuffers
+
+       This indicates the number of buffers available.
+
+     unsigned char **ScanlineColorExpandBuffers
+
+       This is an array of pointers to the memory locations of each buffer.
+       Each buffer is expected to be large enough to accommodate scanlines
+       the width of the screen.  That is:
+
+        ((virtualX + 31)/32) * 4   bytes or more.
+
+        ((virtualX + 62)/32 * 4) if LEFT_EDGE_CLIPPING_NEGATIVE_X is set.
+  
+     Scanlines are always DWORD padded.
+     If the TRIPLE_BITS_24BPP flag is set, the required area should be 
+     multiplied by three.
+
+
+void SetupForScanlineCPUToScreenColorExpandFill(ScrnInfoPtr pScrn,
+        		int fg, int bg,
+			int rop,
+			unsigned int planemask)
+ 
+     Ones in the source bitmap will correspond to the fg color.
+     Zeros in the source bitmap will correspond to the bg color
+     unless bg = -1.  In that case the pixels corresponding to the
+     zeros in the bitmap shall be left unmodified by the accelerator.
+
+     
+void SubsequentScanlineCPUToScreenColorExpandFill(ScrnInfoPtr pScrn,
+			int x, int y, int w, int h,
+			int skipleft )
+
+void SubsequentColorExpandScanline(ScrnInfoPtr pScrn, int bufno)
+
+
+    When SubsequentScanlineCPUToScreenColorExpandFill is called, XAA 
+    will begin transfering the source data scanline at a time, calling  
+    SubsequentColorExpandScanline after each scanline.  If more than
+    one buffer is available, XAA will cycle through the buffers.
+    Subsequent scanlines will use the next buffer and go back to the
+    buffer 0 again when the last buffer is reached.  The index into
+    the ScanlineColorExpandBuffers array is presented as "bufno"
+    with each SubsequentColorExpandScanline call.
+
+    The skipleft field is the same as for the direct method.
+
+    The indirect method can be use to send the source data directly 
+    to a memory mapped aperture represented by a single color expand
+    buffer, scanline at a time, but more commonly it is used to place 
+    the data into offscreen video memory so that the accelerator can 
+    blit it to the visible screen from there.  In the case where the
+    accelerator permits rendering into offscreen video memory while
+    the accelerator is active, several buffers can be used so that
+    XAA can be placing source data into the next buffer while the
+    accelerator is blitting the current buffer.  For cases where
+    the accelerator requires some special manipulation of the source
+    data first, the buffers can be in system memory.  The CPU can
+    manipulate these buffers and then send the data to the accelerator.
+
+
+
+2.6   8x8 Mono Pattern Fills
+
+    XAA provides support for two types of 8x8 hardware patterns -
+    "Mono" patterns and "Color" patterns.  Mono pattern data is
+    64 bits of color expansion data with ones indicating the
+    foreground color and zeros indicating the background color.
+    The source bitmaps for the 8x8 mono patterns can be presented
+    to the graphics accelerator in one of two ways.  They can be
+    passed as two DWORDS to the 8x8 mono pattern functions or
+    they can be cached in offscreen memory and their locations
+    passed to the 8x8 mono pattern functions.  In addition to the
+    GXCOPY_ONLY, ROP_NEEDS_SOURCE, NO_PLANEMASK and RGB_EQUAL flags
+    defined in Section 2.0, the following are defined for the
+    Mono8x8PatternFillFlags:
+
+    HARDWARE_PATTERN_PROGRAMMED_BITS
+
+      This indicates that the 8x8 patterns should be packed into two
+      DWORDS and passed to the 8x8 mono pattern functions.  The default
+      behavior is to cache the patterns in offscreen video memory and
+      pass the locations of these patterns to the functions instead.
+      The pixmap cache must be enabled for the default behavior (8x8 
+      pattern caching) to work.  See Section 3 for how to enable the
+      pixmap cache. The pixmap cache is not necessary for 
+      HARDWARE_PATTERN_PROGRAMMED_BITS.
+
+    HARDWARE_PATTERN_PROGRAMMED_ORIGIN
+
+      If the hardware supports programmable pattern offsets then
+      this option should be set. See the table below for further
+      infomation.
+
+    HARDWARE_PATTERN_SCREEN_ORIGIN
+
+      Some hardware wants the pattern offset specified with respect to the
+      upper left-hand corner of the primitive being drawn.  Other hardware 
+      needs the option HARDWARE_PATTERN_SCREEN_ORIGIN set to indicate that 
+      all pattern offsets should be referenced to the upper left-hand 
+      corner of the screen.  HARDWARE_PATTERN_SCREEN_ORIGIN is preferable 
+      since this is more natural for the X-Window system and offsets will 
+      have to be recalculated for each Subsequent function otherwise.
+
+    BIT_ORDER_IN_BYTE_MSBFIRST
+    BIT_ORDER_IN_BYTE_LSBFIRST
+
+      As with other color expansion routines this indicates whether the
+      most or the least significant bit in each byte from the pattern is 
+      the leftmost on the screen.
+
+    TRANSPARENCY_ONLY
+    NO_TRANSPARENCY
+
+      This means the same thing as for the color expansion rect routines
+      except that for TRANSPARENCY_ONLY XAA will not render the primitive
+      in two passes since this is more easily handled by the driver.
+      It is recommended that TRANSPARENCY_ONLY hardware handle rendering
+      of opaque patterns in two passes (the background can be filled as
+      a rectangle in GXcopy) in the Subsequent function so that the
+      TRANSPARENCY_ONLY restriction can be removed. 
+
+
+
+    Additional information about cached patterns...
+    For the case where HARDWARE_PATTERN_PROGRAMMED_BITS is not set and 
+    the pattern must be cached in offscreen memory, the first pattern
+    starts at the cache slot boundary which is set by the 
+    CachePixelGranularity field used to configure the pixmap cache.
+    One should ensure that the CachePixelGranularity reflects any 
+    alignment restrictions that the accelerator may put on 8x8 pattern 
+    storage locations.  When HARDWARE_PATTERN_PROGRAMMED_ORIGIN is set 
+    there is only one pattern stored.  When this flag is not set,
+    all 64 pre-rotated copies of the pattern are cached in offscreen memory.
+    The MonoPatternPitch field can be used to specify the X position pixel
+    granularity that each of these patterns must align on.  If the
+    MonoPatternPitch is not supplied, the patterns will be densely packed
+    within the cache slot.  The behavior of the default XAA 8x8 pattern
+    caching mechanism to store all 8x8 patterns linearly in video memory.
+    If the accelerator needs the patterns stored in a more unusual fashion,
+    the driver will need to provide its own 8x8 mono pattern caching 
+    routines for XAA to use. 
+
+    The following table describes the meanings of the "patx" and "paty"
+    fields in both the SetupFor and Subsequent functions.
+
+    With HARDWARE_PATTERN_SCREEN_ORIGIN
+    -----------------------------------
+
+    HARDWARE_PATTERN_PROGRAMMED_BITS and HARDWARE_PATTERN_PROGRAMMED_ORIGIN
+
+	SetupFor: patx and paty are the first and second DWORDS of the
+		  8x8 mono pattern.
+
+	Subsequent: patx and paty are the x,y offset into that pattern.
+		    All Subsequent calls will have the same offset in 
+		    the case of HARDWARE_PATTERN_SCREEN_ORIGIN so only
+		    the offset specified by the first Subsequent call 
+		    after a SetupFor call will need to be observed.
+
+    HARDWARE_PATTERN_PROGRAMMED_BITS only
+
+	SetupFor: patx and paty hold the first and second DWORDS of
+		  the 8x8 mono pattern pre-rotated to match the desired
+		  offset.
+
+	Subsequent: These just hold the same patterns and can be ignored.
+
+    HARDWARE_PATTERN_PROGRAMMED_ORIGIN only
+
+	SetupFor: patx and paty hold the x,y coordinates of the offscreen
+		  memory location where the 8x8 pattern is stored.  The
+		  bits are stored linearly in memory at that location.
+
+	Subsequent: patx and paty hold the offset into the pattern.
+		    All Subsequent calls will have the same offset in 
+		    the case of HARDWARE_PATTERN_SCREEN_ORIGIN so only
+		    the offset specified by the first Subsequent call 
+		    after a SetupFor call will need to be observed.
+
+    Neither programmed bits or origin
+
+	SetupFor: patx and paty hold the x,y coordinates of the offscreen 	
+		  memory location where the pre-rotated 8x8 pattern is
+		  stored.
+
+	Subsequent: patx and paty are the same as in the SetupFor function
+		    and can be ignored.
+		  
+
+    Without HARDWARE_PATTERN_SCREEN_ORIGIN
+    -------------------------------------- 
+
+    HARDWARE_PATTERN_PROGRAMMED_BITS and HARDWARE_PATTERN_PROGRAMMED_ORIGIN
+
+	SetupFor: patx and paty are the first and second DWORDS of the
+		  8x8 mono pattern.
+
+	Subsequent: patx and paty are the x,y offset into that pattern.
+
+    HARDWARE_PATTERN_PROGRAMMED_BITS only
+
+	SetupFor: patx and paty holds the first and second DWORDS of
+		  the unrotated 8x8 mono pattern.  This can be ignored. 
+
+	Subsequent: patx and paty hold the rotated 8x8 pattern to be 
+		    rendered.
+
+    HARDWARE_PATTERN_PROGRAMMED_ORIGIN only
+
+	SetupFor: patx and paty hold the x,y coordinates of the offscreen
+		  memory location where the 8x8 pattern is stored.  The
+		  bits are stored linearly in memory at that location.
+
+	Subsequent: patx and paty hold the offset into the pattern.
+
+    Neither programmed bits or origin
+
+	SetupFor: patx and paty hold the x,y coordinates of the offscreen 	
+		  memory location where the unrotated 8x8 pattern is
+		  stored.  This can be ignored.
+
+	Subsequent: patx and paty hold the x,y coordinates of the
+		    rotated 8x8 pattern to be rendered.
+
+
+
+void SetupForMono8x8PatternFill(ScrnInfoPtr pScrn, int patx, int paty,
+        int fg, int bg, int rop, unsigned int planemask)
+
+    SetupForMono8x8PatternFill indicates that any combination of the 
+    following  may follow it.
+
+	SubsequentMono8x8PatternFillRect
+	SubsequentMono8x8PatternFillTrap
+
+    The fg, bg, rop and planemask fields have the same meaning as the
+    ones used for the other color expansion routines.  Patx's and paty's
+    meaning can be determined from the table above.
+
+ 
+void SubsequentMono8x8PatternFillRect( ScrnInfoPtr pScrn,
+        	int patx, int paty, int x, int y, int w, int h)
+
+     Fill a rectangle of dimensions "w" by "h" with origin at (x,y) 
+     using the parameters give by the last SetupForMono8x8PatternFill
+     call.  The meanings of patx and paty can be determined by the
+     table above.
+
+void SubsequentMono8x8PatternFillTrap( ScrnInfoPtr pScrn,
+     			   int patx, int paty, int y, int h, 
+     			   int left, int dxL, int dyL, int eL,
+     			   int right, int dxR, int dyR, int eR )
+
+     The meanings of patx and paty can be determined by the table above.
+     The rest of the fields have the same meanings as those in the 
+     SubsequentSolidFillTrap function. 
+
+
+
+2.7   8x8 Color Pattern Fills
+  
+    8x8 color pattern data is 64 pixels of full color data that
+    is stored linearly in offscreen video memory.  8x8 color patterns 
+    are useful as a substitute for 8x8 mono patterns when tiling,
+    doing opaque stipples, or in the case where transperency is
+    supported, regular stipples.  8x8 color pattern fills also have
+    the additional benefit of being able to tile full color 8x8
+    patterns instead of just 2 color ones like the mono patterns.
+    However, full color 8x8 patterns aren't used very often in the
+    X Window system so you might consider passing this primitive
+    by if you already can do mono patterns, especially if they 
+    require alot of cache area.  Color8x8PatternFillFlags is
+    the flags field for this primitive and the GXCOPY_ONLY,
+    ROP_NEEDS_SOURCE and NO_PLANEMASK flags as described in
+    Section 2.0 are valid as well as the following:
+
+
+    HARDWARE_PATTERN_PROGRAMMED_ORIGIN
+
+      If the hardware supports programmable pattern offsets then
+      this option should be set.  
+
+    HARDWARE_PATTERN_SCREEN_ORIGIN
+
+      Some hardware wants the pattern offset specified with respect to the
+      upper left-hand corner of the primitive being drawn.  Other hardware 
+      needs the option HARDWARE_PATTERN_SCREEN_ORIGIN set to indicate that 
+      all pattern offsets should be referenced to the upper left-hand 
+      corner of the screen.  HARDWARE_PATTERN_SCREEN_ORIGIN is preferable 
+      since this is more natural for the X-Window system and offsets will 
+      have to be recalculated for each Subsequent function otherwise.
+
+    NO_TRANSPARENCY
+    TRANSPARENCY_GXCOPY_ONLY
+
+      These mean the same as for the ScreenToScreenCopy functions.
+
+
+    The following table describes the meanings of patx and paty passed
+    to the SetupFor and Subsequent fields:
+
+    HARDWARE_PATTERN_PROGRAMMED_ORIGIN && HARDWARE_PATTERN_SCREEN_ORIGIN
+	
+	SetupFor: patx and paty hold the x,y location of the unrotated 
+		  pattern.
+
+	Subsequent: patx and paty hold the pattern offset.  For the case
+		    of HARDWARE_PATTERN_SCREEN_ORIGIN all Subsequent calls
+		    have the same offset so only the first call will need
+		    to be observed.
+
+    
+    HARDWARE_PATTERN_PROGRAMMED_ORIGIN only
+
+	SetupFor: patx and paty hold the x,y location of the unrotated
+		  pattern.
+
+	Subsequent: patx and paty hold the pattern offset. 
+
+    HARDWARE_PATTERN_SCREEN_ORIGIN
+
+	SetupFor: patx and paty hold the x,y location of the rotated pattern.
+
+	Subsequent: patx and paty hold the same location as the SetupFor
+		    function so these can be ignored.
+
+    neither flag
+
+	SetupFor: patx and paty hold the x,y location of the unrotated
+		  pattern.  This can be ignored.
+
+	Subsequent: patx and paty hold the x,y location of the rotated
+		    pattern.
+
+    Additional information about cached patterns...
+    All 8x8 color patterns are cached in offscreen video memory so
+    the pixmap cache must be enabled to use them. The first pattern
+    starts at the cache slot boundary which is set by the 
+    CachePixelGranularity field used to configure the pixmap cache.
+    One should ensure that the CachePixelGranularity reflects any 
+    alignment restrictions that the accelerator may put on 8x8 pattern 
+    storage locations.  When HARDWARE_PATTERN_PROGRAMMED_ORIGIN is set 
+    there is only one pattern stored.  When this flag is not set,
+    all 64 rotations off the pattern are accessible but it is assumed
+    that the accelerator is capable of accessing data stored on 8
+    pixel boundaries.  If the accelerator has stricter alignment 
+    requirements than this the dirver will need to provide its own 
+    8x8 color pattern caching routines. 
+
+
+void SetupForColor8x8PatternFill(ScrnInfoPtr pScrn, int patx, int paty,
+        	int rop, unsigned int planemask, int trans_color)
+
+    SetupForColor8x8PatternFill indicates that any combination of the 
+    following  may follow it.
+
+	SubsequentColor8x8PatternFillRect
+	SubsequentColor8x8PatternFillTrap	(not implemented yet)
+
+    For the meanings of patx and paty, see the table above.  Trans_color
+    means the same as for the ScreenToScreenCopy functions.
+
+
+ 
+void SubsequentColor8x8PatternFillRect( ScrnInfoPtr pScrn,
+        	int patx, int paty, int x, int y, int w, int h)
+
+     Fill a rectangle of dimensions "w" by "h" with origin at (x,y) 
+     using the parameters give by the last SetupForColor8x8PatternFill
+     call.  The meanings of patx and paty can be determined by the
+     table above.
+
+void SubsequentColor8x8PatternFillTrap( ScrnInfoPtr pScrn,
+     			   int patx, int paty, int y, int h, 
+     			   int left, int dxL, int dyL, int eL,
+     			   int right, int dxR, int dyR, int eR )
+
+    For the meanings of patx and paty, see the table above. 
+    The rest of the fields have the same meanings as those in the 
+    SubsequentSolidFillTrap function. 
+
+
+
+2.8  Image Writes
+
+    XAA provides a mechanism for transfering full color pixel data from
+    system memory to video memory through the accelerator.  This is 
+    useful for dealing with alignment issues and performing raster ops
+    on the data when writing it to the framebuffer.  As with color
+    expansion rectangles, there is a direct and indirect method.  The
+    direct method sends all data through a memory mapped aperature.
+    The indirect method sends the data to an intermediated buffer scanline 
+    at a time.
+
+    The direct and indirect methods have separate flags fields, the
+    ImageWriteFlags and ScanlineImageWriteFlags respectively.
+    Flags specific to one method or the other are described in sections 
+    2.8.1 and 2.8.2 but for both cases the GXCOPY_ONLY, ROP_NEEDS_SOURCE
+    and NO_PLANEMASK flags described in Section 2.0 are valid as well as
+    the following:
+
+    NO_GXCOPY
+
+      In order to have accelerated image transfers faster than the 
+      software versions for GXcopy, the engine needs to support clipping,
+      be using the direct method and have a large enough image transfer
+      range so that CPU_TRANSFER_BASE_FIXED doesn't need to be set.
+      If these are not supported, then it is unlikely that transfering
+      the data through the accelerator will be of any advantage for the
+      simple case of GXcopy.  In fact, it may be much slower.  For such
+      cases it's probably best to set the NO_GXCOPY flag so that 
+      Image writes will only be used for the more complicated rops.
+
+    /* transparency restrictions */
+
+    NO_TRANSPARENCY
+     
+      This indicates that the accelerator does not support skipping
+      of color keyed pixels when copying from the source to the destination.
+
+    TRANSPARENCY_GXCOPY_ONLY
+
+      This indicates that the accelerator supports skipping of color keyed
+      pixels only when the rop is GXcopy.
+
+    /* clipping  (optional) */
+    
+    LEFT_EDGE_CLIPPING
+ 
+      This indicates that the accelerator supports omission of up to
+      3 pixels on the left edge of the rectangle to be filled.  This
+      is beneficial since it allows transfer from the source pixmap to
+      always occur from DWORD boundaries. 
+
+    LEFT_EDGE_CLIPPING_NEGATIVE_X
+
+      This flag indicates that the accelerator can fill areas with
+      image write data even if the value of x origin is negative (off of
+      the screen on the left edge).
+
+
+2.8.1 The Direct Method
+
+    Using the direct method of ImageWrite XAA will send all
+    bitmap data to the accelerator serially through an memory mapped
+    transfer window defined by the following two fields:
+
+      unsigned char *ImageWriteBase
+
+        This indicates the memory address of the beginning of the aperture.
+
+      int ImageWriteRange
+
+        This indicates the size in bytes of the aperture.
+
+    The driver should specify how the transfered data should be padded.
+    There are options for both the padding of each Y scanline and for the
+    total transfer to the aperature.
+    One of the following two flags must be set:
+
+      CPU_TRANSFER_PAD_DWORD
+
+        This indicates that the total transfer (sum of all scanlines) sent
+        to the aperature must be DWORD padded.  This is the default behavior.
+
+      CPU_TRANSFER_PAD_QWORD 
+
+	This indicates that the total transfer (sum of all scanlines) sent
+	to the aperature must be QWORD padded.  With this set, XAA will send
+        an extra DWORD to the aperature when needed to ensure that only
+        an even number of DWORDs are sent.
+
+    And then there are the flags for padding of each scanline:
+
+      SCANLINE_PAD_DWORD
+
+	This indicates that each Y scanline should be DWORD padded.
+        This is the only option available and is the default.
+
+    Finally, there is the CPU_TRANSFER_BASE_FIXED flag which indicates
+    that the aperture is a single register rather than a range of
+    registers, and XAA should write all of the data to the first DWORD.
+    XAA will automatically select CPU_TRANSFER_BASE_FIXED if the 
+    ImageWriteRange is not large enough to accomodate an entire scanline.   
+
+
+void SetupForImageWrite(ScrnInfoPtr pScrn, int rop, unsigned int planemask,
+        			int trans_color, int bpp, int depth)
+
+     If trans_color is not -1 then trans_color indicates the transparency
+     color key and pixels with color trans_color passed through the 
+     aperature should not be transfered to the screen but should be 
+     skipped.  Bpp and depth indicate the bits per pixel and depth of
+     the source pixmap.  Trans_color is always -1 if the NO_TRANSPARENCY
+     flag is set.
+
+
+void SubsequentImageWriteRect(ScrnInfoPtr pScrn, 
+				int x, int y, int w, int h, int skipleft)
+
+     
+     Data passed through the aperature should be copied to a rectangle
+     of width "w" and height "h" with origin (x,y).  If LEFT_EDGE_CLIPPING
+     has been enabled, skipleft will correspond to the number of pixels
+     on the left edge that should not be drawn.  Skipleft is zero 
+     otherwise.
+
+     It can be arranged for XAA to call Sync() after it is through 
+     calling the Subsequent functions by setting SYNC_AFTER_IMAGE_WRITE 
+     in the  ImageWriteFlags.  This can provide the driver with an
+     oportunity to reset a clipping window if needed.
+
+2.8.2  The Indirect Method
+
+     Using the indirect method, XAA will render the pixel data scanline
+     at a time to one or more buffers.  These buffers may be memory
+     mapped apertures or just intermediate storage.
+
+     int NumScanlineImageWriteBuffers
+
+       This indicates the number of buffers available.
+
+     unsigned char **ScanlineImageWriteBuffers
+
+       This is an array of pointers to the memory locations of each buffer.
+       Each buffer is expected to be large enough to accommodate scanlines
+       the width of the screen.  That is:
+
+         pScrn->VirtualX * pScreen->bitsPerPixel/8   bytes or more.
+
+       If LEFT_EDGE_CLIPPING_NEGATIVE_X is set, add an additional 4
+       bytes to that requirement in 8 and 16bpp, 12 bytes in 24bpp.
+  
+     Scanlines are always DWORD padded.
+
+void SetupForScanlineImageWrite(ScrnInfoPtr pScrn, int rop, 
+				unsigned int planemask, int trans_color, 
+				int bpp, int depth)
+
+     If trans_color is not -1 then trans_color indicates the transparency
+     color key and pixels with color trans_color in the buffer should not 
+     be transfered to the screen but should be skipped.  Bpp and depth 
+     indicate the bits per pixel and depth of the source bitmap.  
+     Trans_color is always -1 if the NO_TRANSPARENCY flag is set.
+
+
+void SubsequentImageWriteRect(ScrnInfoPtr pScrn, 
+				int x, int y, int w, int h, int skipleft)
+
+     
+void SubsequentImageWriteScanline(ScrnInfoPtr pScrn, int bufno)
+
+
+    When SubsequentImageWriteRect is called, XAA will begin
+    transfering the source data scanline at a time, calling  
+    SubsequentImageWriteScanline after each scanline.  If more than
+    one buffer is available, XAA will cycle through the buffers.
+    Subsequent scanlines will use the next buffer and go back to the
+    buffer 0 again when the last buffer is reached.  The index into
+    the ScanlineImageWriteBuffers array is presented as "bufno"
+    with each SubsequentImageWriteScanline call.
+
+    The skipleft field is the same as for the direct method.
+
+    The indirect method can be use to send the source data directly 
+    to a memory mapped aperture represented by a single image write
+    buffer, scanline at a time, but more commonly it is used to place 
+    the data into offscreen video memory so that the accelerator can 
+    blit it to the visible screen from there.  In the case where the
+    accelerator permits rendering into offscreen video memory while
+    the accelerator is active, several buffers can be used so that
+    XAA can be placing source data into the next buffer while the
+    accelerator is blitting the current buffer.  For cases where
+    the accelerator requires some special manipulation of the source
+    data first, the buffers can be in system memory.  The CPU can
+    manipulate these buffers and then send the data to the accelerator.
+
+
+2.9 Clipping
+
+    XAA supports hardware clipping rectangles.  To use clipping
+    in this way it is expected that the graphics accelerator can
+    clip primitives with verticies anywhere in the 16 bit signed 
+    coordinate system. 
+
+void SetClippingRectangle ( ScrnInfoPtr pScrn,
+        		int left, int top, int right, int bottom)
+
+void DisableClipping (ScrnInfoPtr pScrn)
+
+    When SetClippingRectangle is called, all hardware rendering
+    following it should be clipped to the rectangle specified
+    until DisableClipping is called.
+
+    The ClippingFlags field indicates which operations this sort
+    of Set/Disable pairing can be used with.  Any of the following
+    flags may be OR'd together.
+
+	HARDWARE_CLIP_SCREEN_TO_SCREEN_COLOR_EXPAND
+	HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY
+	HARDWARE_CLIP_MONO_8x8_FILL
+	HARDWARE_CLIP_COLOR_8x8_FILL
+	HARDWARE_CLIP_SOLID_FILL
+	HARDWARE_CLIP_DASHED_LINE
+	HARDWARE_CLIP_SOLID_LINE
+
+
+
+3)  XAA PIXMAP CACHE
+
+   /* NOTE:  XAA has no knowledge of framebuffer particulars so until
+	the framebuffer is able to render into offscreen memory, usage
+	of the pixmap cache requires that the driver provide ImageWrite
+	routines or a WritePixmap or WritePixmapToCache replacement so
+	that patterns can even be placed in the cache.
+
+      ADDENDUM: XAA can now load the pixmap cache without requiring
+	that the driver supply an ImageWrite function, but this can
+	only be done on linear framebuffers.  If you have a linear
+	framebuffer, set LINEAR_FRAMEBUFFER in the XAAInfoRec.Flags
+	field and XAA will then be able to upload pixmaps into the
+	cache without the driver providing functions to do so.
+   */
+
+
+   The XAA pixmap cache provides a mechanism for caching of patterns
+   in offscreen video memory so that tiled fills and in some cases
+   stippling can be done by blitting the source patterns from offscreen
+   video memory. The pixmap cache also provides the mechanism for caching 
+   of 8x8 color and mono hardware patterns.  Any unused offscreen video
+   memory gets used for the pixmap cache and that information is 
+   provided by the XFree86 Offscreen Memory Manager. XAA registers a 
+   callback with the manager so that it can be informed of any changes 
+   in the offscreen memory configuration.  The driver writer does not 
+   need to deal with any of this since it is all automatic.  The driver 
+   merely needs to initialize the Offscreen Memory Manager as described 
+   in the DESIGN document and set the PIXMAP_CACHE flag in the 
+   XAAInfoRec.Flags field.  The Offscreen Memory Manager initialization 
+   must occur before XAA is initialized or else pixmap cache 
+   initialization will fail.  
+
+   PixmapCacheFlags is an XAAInfoRec field which allows the driver to
+   control pixmap cache behavior to some extent.  Currently only one
+   flag is defined:
+
+   DO_NOT_BLIT_STIPPLES
+
+     This indicates that the stippling should not be done by blitting
+     from the pixmap cache.  This does not apply to 8x8 pattern fills. 
+
+
+   CachePixelGranularity is an optional field.  If the hardware requires
+   that a 8x8 patterns have some particular pixel alignment it should
+   be reflected in this field.  Ignoring this field or setting it to
+   zero or one means there are no alignment issues.
+
+
+4)  OFFSCREEN PIXMAPS
+
+   XAA has the ability to store pixmap drawables in offscreen video 
+   memory and render into them with full hardware acceleration.  Placement
+   of pixmaps in the cache is done automatically on a first-come basis and 
+   only if there is room.  To enable this feature, set the OFFSCREEN_PIXMAPS
+   flag in the XAAInfoRec.Flags field.  This is only available when a
+   ScreenToScreenCopy function is provided, when the Offscreen memory 
+   manager has been initialized and when the LINEAR_FRAMEBUFFER flag is
+   also set.
+
+   int maxOffPixWidth
+   int maxOffPixHeight
+
+       These two fields allow the driver to limit the maximum dimensions
+     of an offscreen pixmap.  If one of these is not set, it is assumed
+     that there is no limit on that dimension.  Note that if an offscreen
+     pixmap with a particular dimension is allowed, then your driver will be
+     expected to render primitives as large as that pixmap.  
+
+$XFree86: xc/programs/Xserver/hw/xfree86/xaa/XAA.HOWTO,v 1.12 2000/04/12 14:44:42 tsi Exp $