summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authortrappist <trappist>2007-02-07 15:58:08 +0000
committertrappist <trappist>2007-02-07 15:58:08 +0000
commit6e59f828b8f1fef10c172faa1e2a68adbd96832e (patch)
tree94a6775e134e8fe10297b502a56e9dc62e127a57
parent99c7425c4ec4e907dad0bad2bb61360250feff9c (diff)
downloadDocumentation-6e59f828b8f1fef10c172faa1e2a68adbd96832e.tar.gz
Documentation-6e59f828b8f1fef10c172faa1e2a68adbd96832e.tar.bz2
Spelling and stuff
-rw-r--r--Multihead18
1 files changed, 9 insertions, 9 deletions
diff --git a/Multihead b/Multihead
index 720f9a9..2d41b8f 100644
--- a/Multihead
+++ b/Multihead
@@ -3,29 +3,29 @@ WARNING: Incomplete and possibly incorrect information follows.
Multihead is when more than one monitor, projector, tv, etc (head) is
hooked up to the same computer.
-There are two fundamentally diffrent approaches to this in X. Xinerama
+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.
-In the traditional multihead setup, each head provides one screen each.
+In the traditional multihead setup, each head provides one screen.
For beryl, 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, amoung
+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.
Another rather neat result is that you get one cube per head which can
-rotate individual of each other.
+rotate independently of each other.
There isn't much to think about for most programmers when it comes to
multiscreen. Just make sure you don't mix the CompDisplay and CompScreen
data. Also, never use d->screens without cycling through it. On normal
-setups, d->screens reffers to the one and only screen, but on multiscreen,
-it only reffers to the first one. A rule of thumb is to pass the CompScreen
+setups, d->screens refers to the one and only screen, but on multiscreen,
+it only refers to the first one. A rule of thumb is to pass the CompScreen
somehow whenever you know the function will use it. It's safe to get
CompDisplay from screen->display, but not vice versa.
@@ -37,13 +37,13 @@ Xinerama, however, is slightly more complicated. With xinerama, 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 enviroment.
+in diffrent ways in a xinerama-hinted environment.
-For each head in a xinerama hinted enviroment, the paintScreen() procs
+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 is "global perspective"
+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