ShadowFB + Composite + RandR + ?

Tue Sep 27 08:09:51 PDT 2005

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

Keith Packard wrote:
> On Tue, 2005-09-27 at 10:51 +0200, Thomas Winischhofer wrote:
>>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.
> 
> 
> That's wrong...

Good to see that you agree :)

>>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.
> 
> 
> I have no idea why it would do this; I would assume that there's
> something broken in the composite wrappers.
> 
> A stack trace from within the offending functions might be illuminating.

I will try to find out more soon. The whole upper level stuff isn't
really my area of expertise...

In the meantime, I have analyzed the coordinates: It seems that, if the
composite manager is running, there is absolutely no clipping done to
the boxes handed to the refresh handler. If I move a window partly
outside, the coordinates of the boxes are not limited to the framebuffer
dimensions.

As a consequence, the following happens here for example:

I run KDE with kicker in "auto-hide"-mode so that it "scrolls" itself
outside the visible screen whenever the mouse is not over it.

Right after EnableDisableFBAccess(FALSE) and *within* setRootClip(false)
- - so: BEFORE RandR has changed the pScreen structure to the new
dimensions!!! - I receive

1) via PaintWindow() the absolute coordinates of the kicker-window(s)
(it consists of a number of subwindows): My screen is 1280x800, and I
receive like eg.

  x1   x2    y1   y2
 128  1152   800 847

That's where kicker is in hidden state. (128 and 1152 because it doesn't
use the whole screen's width.)

2) later, after all the kicker windows are "redrawn", comes the
following, again via PaintWindow() (with 5 boxes at once):

  x1    x2    y1     y2
  3     4    435    461
  95    4    435    461
  3     4    461    461
  95    4    461    461
  3     4    462    461

Except the first one, all are illegal. They seem to relate to my conso?e
window, which is at the top left screen corner.

A few calls later, a 38-box PaintWindow():
 4    658     0      1
 3    658     1      1
 2    658     2      1
 1    658     3      1
 0    658     4      1

and all of the following have y coordinates whose y1 is bigger than y2.

3) The very last is

  0  1280     0    800

which seems to be the root window.

At this point xf86SetRootClip(FALSE) and EnableDisableFBAccess(FALSE)
return.

Now RandR sets its new screen dimensions. My example is a 90 degree
rotation.

At the end, RandR calls EnableDisableFBAccess(TRUE), which leads to a
xf86SetRootClip(TRUE). This leads to

1) PaintWindow (1 box):

  -1000 -979   -1000 - 986

2) PaintWindow (1 box):

  -1000 -978   -1000 - 978

3) kicker redraw. Kicker doesn't understand that the display is rotated,
so it still paints itself at 128x801 (which is now near the middle of
the rotated screen). But that's kicker's fault. Bad RandR signal handler.

4) Then the following PaintWindow() comes:

  3     4    435    461
  95    4    435    461
  3     4    461    461
  95    4    461    461
  3     4    462    461

Looks familiar, doesn't it...

5) Surprise: Now again that 38-box PaintWindow() arrives, with the exact
same coordinates as above.

Then xf86SetRootClip(TRUE) returns, and so does EnableDisableFBAccess(TRUE).

At this point EXA/XAA re-init their pixmap cache/offscreen memory managers.

Now the screen dimension is 800x1280.

After a few Composite() calls with legal coordinates, bummer....

ShadowPolyFillRect comes along with

  x1   x2    y1    y2
 599  1280   0    800

A few CopyAreas() later, I get a Composite() call with

  -1000 -979   -1000 -986

And again kicker (which I assume from the coords):

  128   1152    800  847

and lots more calls with such coordinates.

(Why is x2 1152, when the screen is only 800 in width? Shouldn't that be
clipped by anybody?)

After that, another Composite():

  1031  1053   813  835

seems to relate to kicker's window as well (which, as we know, still at
800-847 on the y axis)

Now I move my console window beyond the left edge of the screen:

I get a few PaintWindow() calls with coordinates like

   -308 332   400  415

I worked-around this now by checking my refresh box, but something is
really odd here.

Perhaps I should mention that everything looks entirel ok on the rotated
screen - no graphics distortions whatsoever; except, of course, kicker
which is located right in the middle.

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

iD8DBQFDOWC/zydIRAktyUcRAhLrAJ44ggh6zbFBQM72oYzhzPjXzKZgfgCfapOp
mCbKhqAcpHCIvlOlSVpmdb4=
=d4kC
-----END PGP SIGNATURE-----