[compiz] Multihead related issues

[Kristian Lyngstøl]

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.

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'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.

A more serious issue is that we can't share display lists, and that we
need to do OpenGL context switching when we're doing texture work.
Dennis did some excellent work in that area, and it's not a problem in
Beryl at the moment, but as he said himself; It's probably not the
ideal solution. Personally I don't know the best approach to this;
While context switching is generally slow, I don't see any real way
out of it that would be faster, and it doesn't happen all that often
even with Dennis' patches. The OpenGL context switching and sharelist
issue is the big blockers, and where I hope I could get some input.
I'm not sure it's anything we can do with lack of sharelist (?), and
honostly, it's not my field of expertise, but let's see if we can't
figure something out.

There's one last thing related to bigscreen multihead, that hasn't
been fixed in beryl either, and that's option handeling. Compiz-core
of course has the ability to use diffrent options for diffrent
screens, and I'd really like to see this in the storage backends. I'll
admit I haven't been up to date lately, so I don't know the state of
bsm for instance, but I'd like to bring it up now anyway. One use, to
prove that it makes sense, is to have 6x6 viewports on the large
monitor, but only 2x2 on the small (which is what I would want for
myself).

Most of the work shouldn't be to hard to port, but it would be nice to
take this oppertunity to discuss the design and implementation.  I
know perspectives have come up on private e-mails, but since I don't
know the details, I'm bringing it up here.

-- 
Regards
Kristian
PS: The reason I've been a bit passive lately have been a combination
of general IRL bussy-ness, and that I actually use multiscreen and
just felt a bit demotivated that it didn't work. I'm prepared to start
porting or re-implementing multihead-related work as needed.