Remove XAA

Commit 0c6987df in June 2008 disabled XAA offscreen pixmaps per default,
as they were broken, leaving XAA only able to accelerate operations
directly on the screen pixmap and nowhere else, eliminating acceleration
for basically every modern toolkit, and any composited environment.

So, it hasn't worked for over four years.  No-one's even come close to
fixing it.

RIP.

Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
This commit is contained in:
Daniel Stone 2012-07-09 20:04:15 +01:00 • committed by Keith Packard
commit e191e296e6
53 changed files with 28 additions and 24270 deletions

View file

@ -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

View file

@ -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>
@ -3614,14 +3613,6 @@ The following include files are typically required by video drivers:
</filename></literallayout>
</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>
@ -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;

View file

@ -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
------------