Cube setup with two screens -> Two independet cubes

[TB2]

I have two screens and the way compiz cube is behaving is not satisfying at all. Now at the moment there are basically two options:

A) Having one huge cube that has one viewport (which streches over both screens) per cube side. So if the cube is rolled out on a plane surface it's like this, [] being cube sides, V meaning viewport and | being the border between the two screens:

[v1|v1][v2|v2][v3|v3][v4|v4]

B) Having two cubes, one per screen, but still having one viewport per "view" which causes viewports to be split up and distributed over the two cubes. It looks like this, C meaning Cube:

C1[v1]|C2[v1]C1[v2]|C2[v2]]C1[v3]|C2[v3]C1[v4]|C2[v4]

Option A might look alright if you have flat panel TFTs with really narrow borders so you can disregard the gap between the screens, Option B is just silly, because the cubes are mapped in a totally confusing way. Cube 1 always holds only the left part of a viewport and vice versa for Cube 2. And on top of that both cubes are rotating at the same time which makes having two screens useless, as CF always treats the two screens as being one.

What I would like to see, and which shouldn't be too hard to implement is that you would have two indipendent cubes which can be rotated one at a time. You would be able to drag the windows from one cube to another, but you can always spin one cube while the other stays in place. This is the only way two screens make sense to me. It would mean working on one while working on the other on something else, and it makes no sense at all that both screens change upon a viewport change.

The most obvious solution would be to distribute the viewports over the cubes, so that one cube side has one viewport and on 2 cubes with 4 sides you will get 8 viewports which can be managed independently:

C1[v1]C1[v2]C1[v3]C1[v4] | C1[v5]C1[v6]C1[v7]C1[v8]

This is the only way two display make sense to me. I would really appreciate having this option, because neighter of the other two options makes any sense.

[enigma_0Z]

+1

Good idea.

[Jander]

I was only pondering something like this myself over the past couple of days, but a slightly different twist.

What I'd like is a single cube with N faces/viewports, but to have my two screens show different faces of the same cube. I'd want each screen to be able to independently rotate it's cube view. This way I can mix 'n' match my viewports. I tend to have firefox, evolution, rdesktop and a collection of terminal windows up all the time. It'd be good to have them on 4 viewports and then choose which two were visible at what time.

Just my 2p,
Jander.

[some-guy]

+1

Good idea.
another +1

[SmSpillaz]

Hi,

Two independent cubes is not possible with a bigscreen setup (because you would be breaking windows in half, thereby requiring - yes input redirection :-|.

It is however possible with multiscreen, although I'm not sure on how you set that up. Ask adamk

[adamk]

lol...

For multiscreen, there's not much I can add. I've never tried it but it's theoretically as simple as enabling separate screens in your xorg.conf file, disabling twinview, xinerama, and/or mergedfb, and then starting compiz on each screen with the --only-current-screen option.

[adamk]

Oh, and for what it's worth... It seems that E17 does allow you to treat both heads in a twinview/mergedfb/xinerama setup as separate screens. You can move windows between them, of course, but you can also change desktops in just one screen at a time. I'm not sure how they've managed that.

Adam

[some-guy]

@adamk
since when are you 'the grumpy old guy' ;)

[SmSpillaz]

some-guy: Dunno. Maybe he is grumpy and old.

Anyways, I want to try this out, is there any way I can do multiscreen with xrandr? Thanks

[adamk]

I've been the grumpy old guy since I turned 20 :-)

Adam

[Kristian]

(pst: off topic guys)

You do not have to or want to run Compiz once for each screen. Compiz is, or should be capable of managing all screens in one process.

As for doing what you want without multiple screens, I don't see that ever happening, even with input redirection. As a matter of fact, we could do this without input redirection, but it would be more than a little complex, which in turn usually means it would be more than a little bug ridden.

We'd have to cut windows off visually and input-wise, something we can do, then when you change "viewports" to see the other part of the window, we'd have to move the window to cover the other part of the window's input. This is just not fun, and it has very little to do with input redirection, though that could make it slightly simpler, it wouldn't help that much.

[adamk]

Yes, compiz *should* be capable of managing all screens in one process, but I've always heard of various problems (such as menu's not being displayed), which is why I recommended two separate compiz processes (which, I've heard, works).

If I'm wrong about this, and this is not a problem any more, please correct me.

Adam

[()va|_]

What about only one face of the cube being 2nd connected device (tv lcd).

So, on one display1 u have static one side of the cube from display2.

So no matter what you do on display2, on display1 u always see only one side of display2 cube.
Basicley, the display2 is rotating moving etc. but one side od the cube is 2nd display, with only 1 side (of the display2's cube) displaying at all times on it.

That would be a great for presentations, playing movies etc.

I'm sorry for my horror english and hope u can understand this :)

[Kristian]

What about only one face of the cube being 2nd connected device (tv lcd).

So, on one display1 u have static one side of the cube from display2.


You can more or less achieve this by setting sticky on all the windows on one head, the only difference is that this will still have an animation.

I'll think about this a bit, maybe we can just filter out the animation for a given head, that shouldn't be too difficult, and it does make sense.

[b0le]

I have made some patches to do that ^^^ , they are now on bugzilla (http://bugs.opencompositing.org/show_bug.cgi?id=722), if you want to test them