summaryrefslogtreecommitdiff
path: root/Documentation/Multihead
blob: 2d41b8f70415327f500ec06be6c97a7e73de4379 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
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 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.
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, 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 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 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.

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
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?)

Author: Kristian LyngstĂžl <kristian@beryl-project.org>