ShadowFB + Composite + RandR + ?

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


While implementing (hardware accelerated) rotation support into the sis
driver, I experienced a few odd issues with the combination of a running
composite mgr, shadow fb and randr:

1) RandR calls EnableDisableFBAccess(FALSE) before doing its changes in
xf86RandRSetMode(). At the end of this procedure, it calls
EnableDisableFBAccess(TRUE).

2) EXA and XAA swap out their pixmaps upon EnableDisableFBAccess(FALSE).
Their wrapper of pScrn->EnableDisableFBAccess looks like this:

   if(!enable) {
      swapout();
   }

   private->EnableDisableFBAccess();

   if(enable) {
      swapin();
   }

3) So, the very first step upon a RandR-SetMode() is to swap out all
pixmaps (in other words: to destroy all offscreen areas), then to call
the "real" EnableDisableFBAccess(). (The EXA/XAA part of this
explanation is only there to illustrate that I need to buffer the boxes
while I have no offscreen area to render the rotated display into.)

The "real" EnableDisableFBAccess() is in xf86Helper.c and calls
xf86SetRootClip().

4) Summary: Upon a RandR-SetMode(), the following is done:

   - EXA/XAA swap out
   - setRootClip(false)
   - mode change, RandR-changes to pScreen structure
   - setRootClip(true)
   - EXA/XAA re-init their offscreen stuff

5) Now for the problem:

If no composite manager is running, setRootClip(false) does not cause
any calls to functions which are wrapped by shadowfb, especially not
pScreen->PaintWindow[Border|Background](). That's the way it should be.

However, if a composite manager is running, xf86SetRootClip(false)
*does* cause a few calls to pScreen->PaintWindow[Border|Background](),
which - due to shadowfb - end up in the driver's refresh routine.

Not only should this IMHO not happen at all (after all,
setRootClip(false) is supposed to "disable rendering to the screen"),
the regions (boxes) that are handed to the driver's refresh function
have illegal coordinates like (-1000, -976), (-1000, -986) and the like.
Apart from negative values, they sometimes also exceed the valid range
in both x and y directions.

Can anyone (Keith?) explain what's going on?

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOQgpzydIRAktyUcRArYlAJ9GYaEErs4vVmFvtJfT0wjar1mUvQCgtcjP
QLCysxS2ie4jY1rWjUacFcY=
=lYfP
-----END PGP SIGNATURE-----