summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKristian Lyngstol <kristian@bohemians.org>2007-06-22 14:56:09 +0200
committerKristian Lyngstol <kristian@bohemians.org>2007-06-22 14:56:09 +0200
commit3f6aed23f92afc56e4f255b2e0786e594d6a6466 (patch)
tree327697bb93225a363701156ff12782bbd7da64ec
parent2af57c9d57aa352025ca8c865ed08065637460e4 (diff)
downloadDocumentation-3f6aed23f92afc56e4f255b2e0786e594d6a6466.tar.gz
Documentation-3f6aed23f92afc56e4f255b2e0786e594d6a6466.tar.bz2
Update for Compiz Fusion
-rw-r--r--Multihead66
1 files changed, 37 insertions, 29 deletions
diff --git a/Multihead b/Multihead
index cc3f85f..7f428e4 100644
--- a/Multihead
+++ b/Multihead
@@ -4,7 +4,7 @@ Multihead and beryl
===================
0. Scope of this document
1. Two fundamentally diffrent ways of doing multihead
-2. What beryl needs from X
+2. What Compiz needs from X
3. Code-related concerns.
@@ -23,23 +23,24 @@ There are two fundamentally different approaches to this in X. Xinerama
and "multiscreen" or traditional multihead.
Note that certain hardware vendors implement their own xinerama-like
-functionality. Examples are nVidia's TwinView and ATI's bigdesktop.
+functionality. Examples are nVidia's TwinView and ATI's mergedfb, also
+xrandr acts the same way for what plugins are concerned.
In the traditional multihead setup, each head provides one screen.
-For beryl, this means one CompScreen each. They share the same display.
+For Compiz, this means one CompScreen each. They share the same display.
For two heads, this would give us a DISPLAY variable :0.0 for the first
screen, and :0.1 for the second. These heads are mostly independent of
each other. This means windows can't be moved between them, among
other things. The main reason for using this setup is for people with
multiple video cards. It's easier to provide several screens with
the needed functionality (dri, composite, etc) when you are using
-several video cards than it is to provide a single xinerama screen.
+several video cards than it is to provide a single big screen.
Another rather neat result is that you get one cube per head which can
rotate independently of each other.
-2. What beryl needs from X
-==========================
-Beryl supports both xinerama-hinted multihead, and multiscreen. However, that
+2. What Compiz needs from X
+===========================
+Compiz supports both bigscreen multihead, and multiscreen. However, that
does not mean it will work.
With nVidia, you should have no real problems. Just set up TwinView and you
@@ -51,9 +52,9 @@ FIXME: Better input from Intel/ATI users.
ATI users might run into problems, as the open source drivers does not provide
DRI on both screens in multihead.
-Beryl needs a working AIGLX, Xgl or nVidia rendering path for all screens
-to work. Beryl also needs composite working on all screens. Check for these
-in the X log if you are having trouble starting beryl on multiscreen.
+Compiz needs a working AIGLX, Xgl or nVidia rendering path for all screens
+to work. Compiz also needs composite working on all screens. Check for these
+in the X log if you are having trouble starting Compiz on multiscreen.
3. Code-related concerns.
=========================
@@ -70,26 +71,33 @@ The biggest challange with multiscreen is knowing when to share what. If
you're unsure, save on a per-screen basis. It might duplicate information
in multiscreen, but at least it will work.
-Xinerama, however, is slightly more complicated. With xinerama, we only
+For multiscreen you also have to make sure the OpenGL context is correct
+before modifying textures. This can easily be done by passing
+makeScreenCurrent (s) before modifying a texture.
+
+Bigscreen, however, is slightly more complicated. With bigscreen, we only
deal with one CompScreen, but the screen->outputDev comes into play.
Remember the difference between the monitor width and screen width for
-instance. In addition to that, Beryl also sets up the Projection matrix
-in diffrent ways in a xinerama-hinted environment.
-
-For each head in a xinerama-hinted environment, the paintScreen() procs
-are called. This means you have to keep track of where you are properly,
-so you don't accidently draw on both heads.
-
-The two projection setups that exist at the moment are "global perspective"
-and "local perspective". With a global perspective, the perspective is
-centered around the entire _screen_. This requires switching the
-projection matrix when the OpenGL viewport is changed from one head
-to another. This is handled by core. The local perspective means that
-the perspective is centered at each head. This requires no switch in the
-projection matrix (except the inital setup of course). Global perspective
-is used for "OneBig cube" and local perspective is used for
-"Multiple cubes".
-
-(more coming?)
+instance. In addition to that, Compiz also sets up different CompOutput
+targets for drawing.
+
+For each head in a bigscreen environment, the paintOutput() procs
+are called. They are called at the "bottom" of the paintScreen (), which is
+only called once per actual screen. The fullscreenOutput also makes things
+even more difficult, which is a special CompOutput which causes us to draw
+to the entire screen, not just one head.
+
+The reason you have to deal with fullscreenOutput is the OpenGL viewport.
+Usually we draw each head by it self, and that's fine, but this means we
+move the OpenGL viewport for each draw, but we do not adjust the projection
+matrix. That means that if you zoom out to the same coordinates on two heads
+without s->fullscreenOutput, you will break the picture, because you are
+zooming two different images to the center of EACH screen. Using
+s->fullscreenOutput means that you draw "both" images as one, and therefor
+don't break them when you zoom them.
+
+You want to use fullscreenOutput whenever you are doing animations that
+affect the entire viewport, like cube rotations (still doesn't do it at
+present, and the result is obvious), expo and more.
Author: Kristian LyngstĂžl <kristian@beryl-project.org>