Comment 51 for bug 156550

(In reply to comment #12)
> > Overlapping Xinerama geometry has always been legal. That's how
> > people do crazy things like overlap the edges of projectors to correct
> > for vignetting. Newer versions of RANDR merely exacerbate the
> > problem by making overlapping geometry much more common,
> > because it tries to clone all screens together if it can.
>
> Well something has changed recently, because now I'm getting mail from
> people saying "hey, xscreensaver is suddenly not covering my screen".
> These are not people doing crazy stuff with projectors, these are people
> with out-of-the-box one-screen setups (or possibly, people with laptops)
> who had this crap just suddenly start *happening* to them, because on
> their vanilla setup, xinerama is suddenly reporting two screens that overlap.

Right. RANDR propagates its output geometry into the Xinerama protocol, so that
clients that are only aware of Xinerama stand a chance of doing the right thing.
 RANDR also defaults to cloning the desktop by default (as much as it can), and
attempts to do this even for outputs where we can't really tell if they're
connected, like S-Video.

Therefore, the driver probably presents a "definitely connected" screen at, say,
1600x1200, and a "possibly connected" screen at some fallback size. 1360x768 is
certainly not a _good_ fallback size, but that's my bug, not yours. (I have a
fix for it, just need to get it reviewed.)

> 2) When I am presented with two overlapping xinerama rectangles,
> what am I expected to do, exactly?
>
> The "just ignore it and use xinerama geometry" approach leads to me
> creating two xscreensaver root-windows, which overlap, and running
> savers on each of them.

Sorry, I should have been clearer here. While the Xinerama geometry might be
useful for telling you how monitors are physically placed, the logical rendering
model is still that every pixel is presented once, uniquely, and that any
geometry info you get out of RANDR or Xinerama is just telling you how many of
those pixels are physically being displayed and where they are in relation to
each other.

The root window is the canvas. Extended geometry describes how much of the
canvas is occluded from view, and gives hints about where to place menus so
they're all on one screen and whatnot. If you paint to the bounding box
covering all extended geometry, the output should look right.

You might as an optimization create just one window per output, if they're all
completely disjoint, as that will save some memory and probably perform better.
 But any overlap should be handled by painting to the screen as though it's a
solid canvas, meaning, find the bounding box of all the Xin rects and make a
window that size.

I wonder how OSX handles this. I suspect they just don't allow any overlap
cases besides exact cloning.