compiz - Feb 2009 - Clipped screen when using multiple X screens (regression) ?

Please see the Ubuntu bug report for photographs and logs of this
problem "Clipped area for multiple X screens with different
dimensions":

https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/331918

Thanks to some great support and suggestions in #compiz-fusion-dev I've
made some progress in trying to pin this issue down.

I've operated with compiz and multiple X screens for about 2 years, both
on nvidia GeForce Go 7600 and Matrox G450 dual-head.

I'm now testing for Ubuntu Jaunty and met an apparent regression.

The problem appears to be that compiz is getting screen 0 geometry for
screen 1, and as screen 0 is 800 pixels high and screen 1 is 1024 pixels
high, screen 1 ends up with a black band across the lower section of the
monitor that appears to be 224 (1024-800) pixels high.

The issue occurs when compiz manages both screens and when it manages
just screen 1:

DISPLAY=:0.1 compiz --replace --only-current-screen ...

After doing a lot of investigation and testing of the current Ubuntu
Jaunty package (1:0.7.9+git20090211-0ubuntu4) with various debug logging
I began bisecting.

I started at the last known good package (1:0.7.4-0ubuntu7). That works
find on Ubuntu Hardy 8.04.2.

Building that package on Jaunty I found it suffers the same problem.

Originally I tagged the bug as being in Xorg and then discounted that
when I found it was specific to Compiz.

Now however, I'm beginning to wonder if the newer xserver packages have
a problem and are incorrectly returning screen 0 geometry at some point.

So, can you tell me which calls to the xserver will return the geometry
of the screen(s) that compiz will rely on for clipping so I can include
some debug logging to test the return values?

Thanks.

Hi,
> The problem appears to be that compiz is getting screen 0 geometry for
> screen 1, and as screen 0 is 800 pixels high and screen 1 is 1024 pixels
> high, screen 1 ends up with a black band across the lower section of the
> monitor that appears to be 224 (1024-800) pixels high.
> 
> The issue occurs when compiz manages both screens and when it manages
> just screen 1:
> 
> DISPLAY=:0.1 compiz --replace --only-current-screen ...
> 
> After doing a lot of investigation and testing of the current Ubuntu
> Jaunty package (1:0.7.9+git20090211-0ubuntu4) with various debug logging
> I began bisecting.
> 
> I started at the last known good package (1:0.7.4-0ubuntu7). That works
> find on Ubuntu Hardy 8.04.2.
> 
> Building that package on Jaunty I found it suffers the same problem.
> 
> Originally I tagged the bug as being in Xorg and then discounted that
> when I found it was specific to Compiz.
> 
> Now however, I'm beginning to wonder if the newer xserver packages have
> a problem and are incorrectly returning screen 0 geometry at some point.
> 
> So, can you tell me which calls to the xserver will return the geometry
> of the screen(s) that compiz will rely on for clipping so I can include
> some debug logging to test the return values?
Initially, compiz gets the screen geometry by querying the dimensions of
the root window of the respective screen (using XGetWindowAttributes in
src/screen.c, function addScreen). If a screen is reconfigured, it gets
the new size from the ConfigureNotify event (src/screen.c, function
configureScreen).

Regards,

Danny