EXA composite ops don't report damage

[Daniel Drake]

Hi,

I am investigating a bug in AbiWord where when the screen is rotated,
newly inputted text does not appear in the document. This is affecting
OLPC XO.

The graphics driver
(http://dev.laptop.org/git/projects/xf86-video-dove/) implements
screen rotation via EXA, i.e. it supports composite operations with a
rotation transform applied.

I audited the EXA composite requests from the driver level, dumping
images for the source and dest pixmaps before executing the composite
op, and also the dest pixmap after compositing. My conclusion is that
the driver is doing what it is told.

I can see that the system maintains two big pixmaps - one of the
unrotated screen, and one of the rotated screen (which is shown on the
display). When the unrotated screen is changed, the changed areas are
composited onto the rotated screen. However, in the case of new text
input, the new characters are composited onto the unrotated screen,
but no corresponding composite operation happens in order to update
the rotated screen pixmap.

Turning to to the X server. In xf86Rotate.c I can see that changes to
the screen are tracked by the damage system: when damage is detected,
appropriate composite ops are generated in order to keep the rotated
screen pixmap up to date. In the case of newly input text, no damage
is detected.

Looking in miext/damage/damage.c, I see that it attemps to hook onto
the Composite handler chain so that it knows when parts of the screen
have been updated due to composite operations. But here is where I am
confused.

When EXA handles the composite request in accelerated fashion (e.g.
exaComposite -> exaTryDriverComposite -> driver's composite handler),
it does *not* continue calling down the Composite chain. So in the
composite operation where AbiWord's updated document canvas (with my
newly input text) is composited onto the unrotated screen pixmap, the
damageComposite() handler is never called, so its not surprising that
the damage layer is not aware of this screen update.

Is this a bug? How is this supposed to work?

EXA does continue calling down the Composite chain (correctly calling
into damage.c) in the case where the operation could not be
accelerated (i.e. from ExaCheckComposite() in exa_unaccel.c). But in
this case, since the driver accelerated the operation, this code was
not hit.

Thanks,
Daniel