[PATCH] complete (I hope!) i830 EXA support

[Bernhard Kaindl]

> > I830DRIInitBuffers
> > symbol lookup error: /usr/X11R6/lib/modules/drivers/i810_drv.so:
> > undefined symbol: XAAGetPatternROP
> 
> Hm, I must have missed a call to that routine, but I don't see where.  
> Are you using the latest version of the driver?  It's at 
> http://www.virtuousgeek.org/patches/i830-exa-latest.patch.

Yes, I also have made sure that some transparent proxy didn't trick
me by verifying the md5sume using another path. I tested a bit:

The place where XAAGetPatternROP was called was from I830SetupForSolidFill
(found in i830_xaa.c) which in turn was called from  I830DRIInitBuffers
(found in i830_dri.c) which you see also as the last debug message above.

> So you're using the patch but using "AccelMethod" "XAA"? I've only
> tested that a little, so there may be bugs when both EXA and XAA 
> support are compiled into the driver.

No, the patch enabled XAA and EXA in parallel by default and I selected
EXA in the xorg.conf which is confirmed in the initaliation messages.

I think it makes sense to compile both by default as long as there 
is still some valid reason why to use XAA. I don't know but if XAA
could become obsolete by EXA and unmaintained, then the ifdefs could
be good to isolate the code which could be deleted at a later date.

In the latest patch, the DRI functions call the old *SolidFill and
*ScreenToScreenCopy functions which in turn call functions which
use XAA ROP functions.

I have temporarily removed all *Solid* buffer initialiation and screen
copy routines which did the the the XAA ROP and got a somewhat working.

"Somewhat" means that glxgears and games like gl-117 and glest worked
as long as they didn't attempt fullscreen, if they did, I had to
start them using this example command:

(sleep 0.5;killall -STOP xcompmgr) & glest; killall -CONT xcompmgr

I needed the same command with nvidia drivers a while ago with composite,
it prevents the composing manager from interfering while the DRI app is
running fullscreen. If the compositing mangare was not stopped, problems
with keyboard/mouse input focus, video mode switching and window placement
for fullscreen occured (occur with the i915 composite with this patch)

Also, at least with the patched i915 driver, the DRI output drawing does
not take windows which overlap the DRI window into account, so the DRI
output overdraws all drawing of windows which overlap the DRI window.
Of coruse, also transset only applies to the window decoration of the
DRI window, but not it direct rendering output.

I guess this could be solved, taking also shadows and transparency
into account, using rendering to an offscreen buffer, but of course
at a performance and latency penalty, so indeed Xglx/Xegl would be
interesting there.

Bernhard

PS:
To replace the code which I temporariliy removed for testing, I looked
a but at the existing code, but a tip would be needed here:

The code for clearing the front (=window) buffer in I830DRIInitBuffers
could look like this, but I don't know which PixmapPtr I can use for
initializing the solid fills:

pI830->EXADriverPtr->accel.PrepareSolid(<<which PixmapPtr??>>, GXcopy, 0xffffffff, 0);
while (nbox--)
{
  pI830->EXADriverPtr->accel.Solid(pWin->drawable, pbox->x1, pbox->y1,
                                  pbox->x2 - pbox->x1, pbox->y2 - pbox->y1);
  pbox++;
}
pI830->EXADriverPtr->accel.DoneSolid (pWin->drawable);

Similar code is needed for clearing the depth buffer and for window moves
to use EXA acceleration where I removed the current XAA-dependent code.