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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
