[compiz] Multihead related issues

[Kristian Lyngstøl]

On 4/13/07, David Reveman <davidr at novell.com> wrote:
> On Thu, 2007-04-12 at 11:57 +0200, Kristian Lyngstøl wrote:
> > First, there are two fundamentally diffrent types of doing multihead:
> > The "one big screen" solution, usually achieved with xinerama ,
> > twinview or similar. This provides us with one Screen, and therefor
> > one CompScreen structure. The output extens are retrieved from
> > xinerama, or possibly randr (in the future?), I would assume.
> >
> > Then there is the less used "multiscreen" way, which gives two
> > seperate screens; you can't move windows across them, but you can also
> > change the viewports individually.
> >
> > Compiz allready has the basic support for both of these setups, but
> > within the Beryl modifications, we had some important changes.
> >
> > First, the perspective fixes, or projection-matrix related fixes.
> >
> > "Bigscreen" multihead is drawn by drawing one head at a time, and
> > moving the OpenGL viewport for each. The problem with this approach is
> > that the projection matrix is NOT altered, so it is centered around
> > each head. This introduces a problem when you perform effects on more
> > than one head: Say you zoom the cube out, you will first zoom to the
> > center of head A, then when it comes time to draw head B, it will be
> > zoomed with regards to the center of B.
>
> If you want to draw all heads as one, then we should probably make it
> possible to do that and not try to emulate it by manipulating the
> projection matrix.

That would be a good solution too. What were your main reasons for
drawing one head at a time? I'm also curious if there are any
performance benefits of doing that, over drawing one huge scenery (say
you're using 4 monitors or more, it'll be a pretty huge viewport). The
only drawback I can think of drawing in one go is offscreen areas,
usually caused by  mixed resolutions, but could also be caused by
having 3 monitors, two placed next to each other and the last on top.


> > In Beryl, we solved this by calculating the respective "global"
> > projection matrix for each head, storing it, and switching the
> > projection matrix when we switch the viewport. This works excellently,
> > and introduces minimum overhead; Since the projection matrix is
> > pre-computed, it's just a matter of switching. I can't imagine a more
> > efficient or correct way of doing this, though maybe the
> > implementation could be improved. Without the projection-matrix fixes,
> > bigscreen multihead will allways zoom incorrectly, unless you
> > introduce some modelview matrix transformation to take over the job
> > that the projection matrix was made for.
> >
> > Then there's multiscreen, which is a diffrent chapter. Without the
> > beryl-work in multiscreen, it's unusable. However, the changes may not
> > be perfect. There are a few really minor situations where d->screens
> > is used instead of passing the actual screen to a function, those are
> > trivial to work out and there are some changes to "Screen grabs"
> > (Screen grabs are broken by design atm; They grab input, but are
> > screen-specific and are used to communicate(!) drawing-related events
> > too.). We need to figure out what we want to do with screen grabs;
> > What I did in Beryl was to make sure that the screen grabs are manged
> > in a display-context kinda way, but it's not a good long-term
> > solution. Without it, however, you'll be able to do things like snap
> > both cubes to the top, unsnap one, and now you have 0 screen grabs,
> > even though one cube is snapped and SHOULD have a screen grab, and
> > basicly you'll freez if you try to use the snapped cube most of the
> > time. This is just an example.
>
> I'm not sure how useful multiscreen will be in the future. Once input
> transformations and randr 1.2 is integrated properly there's nothing
> multiple screens can do that one screen can't, except drive multiple
> graphics cards. What are you using it for?

The main reason we fixed it up was for multiple graphics cards;
situations where a xinerama-hinted enviroment just wouldn't work.
After I started using it myself for development, though, I fell in
love with the ability to switch viewports independantly. I use my two
monitors for diffrent things, so I don't really want the viewports to
be bound to each other.

You're right that it's not terribly usefull, of course, but
considering Compiz is allready designed to handle it, I don't think
there's any reason not to support it at this point.

> Some basic support for multiple screens should probably be there and I'm
> interested in whatever fixes you have.
>
> The screen grabs should probably be removed at some point and simply
> replaced by exclusive keyboard and pointer grabs much like XGrabKeyboard
> and XGrabPointer.

Maybe I missed something, but isn't that more or less exactly what
they do allready, except they're used a little bit more creativly?

> > I've been wanting to redo some of the screen grab work by splitting it
> > in two; Seperate what's actually grabbing input from what's used to
> > signal that something drawing-related is happening.
>
> I wonder if we need the drawing-related grabbing.

Not sure how we can avoid it completly, we'll still need to know of an
event was triggered as a side-effect of something that grabs the
screen or not. (EnterNotify events while moving windows/grabbing cube
for instance).

I'll start working on the multiple screen related fixes and see if I
can't get them to you.

-- 
Kristian