summaryrefslogtreecommitdiff
path: root/hw/xfree86/doc
diff options
context:
space:
mode:
Diffstat (limited to 'hw/xfree86/doc')
-rw-r--r--hw/xfree86/doc/README.modes9
-rw-r--r--hw/xfree86/doc/ddxDesign.xml50
-rw-r--r--hw/xfree86/doc/exa-driver.txt9
3 files changed, 11 insertions, 57 deletions
diff --git a/hw/xfree86/doc/README.modes b/hw/xfree86/doc/README.modes
index 894e21313..ea228e592 100644
--- a/hw/xfree86/doc/README.modes
+++ b/hw/xfree86/doc/README.modes
@@ -133,11 +133,10 @@ this function computes an initial configuration for the server. It tries to
enable as much hardware as possible using some fairly simple heuristics.
The 'canGrow' parameter indicates that the frame buffer does not have a fixed
-size (fixed size frame buffers are required by XAA). When the frame buffer
-has a fixed size, the configuration selects a 'reasonablely large' frame
-buffer so that common reconfiguration options are possible. For resizable
-frame buffers, the frame buffer is set to the smallest size that encloses
-the desired configuration.
+size. When the frame buffer has a fixed size, the configuration selects a
+'reasonablely large' frame buffer so that common reconfiguration options are
+possible. For resizable frame buffers, the frame buffer is set to the smallest
+size that encloses the desired configuration.
3.2 ScreenInit functions
diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
index ce81a9d5d..4c2ca47da 100644
--- a/hw/xfree86/doc/ddxDesign.xml
+++ b/hw/xfree86/doc/ddxDesign.xml
@@ -330,8 +330,8 @@ that. This is a significant difference compared with the old design.
<para>
The entry points for drawing operations are already taken care of by
-the framebuffer code (including, XAA). Extensions and enhancements to
-framebuffer code are outside the scope of this document.
+the framebuffer code. Extensions and enhancements to framebuffer code
+are outside the scope of this document.
</para>
<para>
@@ -2003,10 +2003,9 @@ also include the video card's saved state.
</para>
<para>
-Per-screen data for other modules that the driver uses (for example,
-the XAA module) that is reset for each server generation is hooked into
-the <structname>ScrnInfoRec</structname> through it's <structfield>privates</structfield>
-field.
+Per-screen data for other modules that the driver uses that is reset for each
+server generation is hooked into the <structname>ScrnInfoRec</structname>
+through its <structfield>privates</structfield> field.
</para>
<para>
@@ -3615,14 +3614,6 @@ The following include files are typically required by video drivers:
</para>
<para>
- If a driver uses XAA, it needs these:
- <literallayout><filename>
- "xaa.h"
- "xaalocal.h"
- </filename></literallayout>
- </para>
-
- <para>
If a driver uses the fb manager, it needs this:
<literallayout><filename>
"xf86fbman.h"
@@ -3840,31 +3831,6 @@ manager is allowed to manage. This is typically a box with a width of
can be fit within the total video memory, however, the driver can reserve
areas at the extremities by passing a smaller area to the manager.
</para>
-
- <para>
-<function>xf86InitFBManager()</function> must be called before XAA is
-initialized since XAA uses the manager for it's pixmap cache.
- </para>
-
- <para>
-An alternative function is provided to allow the driver to initialize
-the framebuffer manager with a Region rather than a box.
-
- <programlisting>
- Bool xf86InitFBManagerRegion(ScreenPtr pScreen,
- RegionPtr FullRegion);
- </programlisting>
-
-<function>xf86InitFBManagerRegion()</function>, unlike
-<function>xf86InitFBManager()</function>, does not remove the area used for
-the visible screen so that area should not be included in the region
-passed to the function. <function>xf86InitFBManagerRegion()</function> is
-useful when non-contiguous areas are available to be managed, and is
-required when multiple framebuffers are stored in video memory (as in
-the case where an overlay of a different depth is stored as a second
-framebuffer in offscreen memory).
- </para>
-
</sect1>
<sect1 id="cmap">
@@ -8900,12 +8866,6 @@ ZZZPreInit(ScrnInfoPtr pScrn, int flags)
ZZZFreeRec(pScrn);
return FALSE;
- /* Load XAA if needed */
- if (!pZzz-&gt;noAccel || pZzz-&gt;hwCursor)
- if (!xf86LoadSubModule(pScrn, "xaa")) {
- ZZZFreeRec(pScrn);
- return FALSE;
- }
/* Done */
return TRUE;
diff --git a/hw/xfree86/doc/exa-driver.txt b/hw/xfree86/doc/exa-driver.txt
index 048307ee7..da39d3f91 100644
--- a/hw/xfree86/doc/exa-driver.txt
+++ b/hw/xfree86/doc/exa-driver.txt
@@ -8,15 +8,10 @@ from system memory, and Porter-Duff compositing and transform operations.
Configuration
-------------
-A new config file option, AccelMethod, should be added to your driver, to allow
-the user to select between the EXA and XAA acceleration APIs.
-
Some drivers implement a per-instance useEXA flag to track whether EXA is
-active or not. It can be helpful to also conditionalize XAA support with an
-ifdef so that it can easily be turned off/removed in the future.
+active or not.
-Setting the flag and checking for AccelMethod can be done in the driver's
-Options parsing routine.
+Setting the flag can be done in the driver's Options parsing routine.
Loading EXA
------------