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.
>
> 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?
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.
>
> 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.
>
> 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.
>
- David