From: Allan Schaffer (allan++at++sgi.com)
Date: 02/13/2000 14:43:59
On Feb 13, 2:33pm, Tammy Martin wrote:
> Does anyone know how to configure the dual monitors on the
> SGI Octane to work as one large screen? I would like the
> capability to move graphics windows from one monitor to the other
> monitor just like they were one large X-Windows screen?
You can't.
With multiple graphics heads such as the 'dual-head' options on
Octane each head operates as a separate X screen, totally independent
of the others. You can open up windows individually on each screen
of course but can't move them from one to the other, and can't have a
single window spanning multiple X screens.(*)
(*) Only exception is the cursor. There's some extra magic built in
to make it disappear on one screen and appear on another when you
move it from head to head.
[All this is a completely different beast than a multi-channel setup
such as that on the InfiniteReality system or Octane Channel
Option. In those cases you -can- move windows from one 'monitor' to
another, because each monitor is simply displaying a pixel-offset
region of the same framebuffer.]
It's pretty easy to get this terminology confused since X windows
takes some rather mundane words (screen, display, etc) and gives them
distinct meaning. Grabbing from an earlier writeup:
An X screen has a one-to-one mapping with the concepts embodied in a
pipe, a head, a framebuffer. An X display is a collection of X
screens, all tied together with a single input event stream (ie, one
keyboard & mouse). A channel (typically representing a single
viewport) in these terms is a pixel-offset region of the framebuffer
and is displayed by the monitor on your desk.
Given the X ":display.screen" notation,
ie: setenv DISPLAY :0.0
- There's a 1-to-1 correlation of X screens to graphics pipes.
- An X Display is made up of one or more X screens (:0.0, :0.1, etc)
- each X Display loosely corresponds to one user -- literally, one
input stream.
- There is one X server (Xsgi) per X Display.
The hierarchy is display<--screen<--channel
So on a single-pipe system, there is:
- one keyboard, so one X Display (0)
- one framebuffer, so one X Screen (:0.0).
- possibly multiple channels (pixel offset in the framebuffer, all on :0.0)
On a two-pipe system, there are two possibilities, depending upon
whether it's a single-keyboard or multi-keyboard config:
either
- one keyboard, one X Display (0)
- two framebuffers, two X screens (:0.0 and :0.1)
- possibly multiple channels (pixel offset in each framebuffer)
or
- two keyboards, two X Displays (0 and 1)
- two framebuffers, two X screens [one on each display] (:0.0 and :1.0)
- possibly multiple channels (pixel offset in each framebuffer)
It's easiest to visualize this hierarchy with a diagram. An Onyx2
InfiniteReality system with one keyboard, two pipes, three channels
on the first pipe, and four channels on the second pipe would have a
X control layout as follows:
/--Channel (0,0 - 1280, 512)
/--- X Screen <-- Channel (0,512 - 640,1024)
/ \--Channel (640,512 - 1280,1024)
/
X Display
\
\ /--Channel (0,0 - 640,512)
\--- X Screen <-- Channel (640,0 - 1280,512)
\--Channel (0,512 - 640,1024)
\-Channel (640,512 - 1280,1024)
(I made up the positioning of the channels; tools like ircombine or
setmon are what you use for this)
So, the immobile barrier for a window -- or anything on the display
-- is the X screen. You can move a window around on its own X screen
(and perhaps this window will be partially visible in the various
channels) but you can't move it or overlap from screen to screen.
Allan
-- Allan Schaffer allan++at++sgi.com Silicon Graphics http://reality.sgi.com/allan
This archive was generated by hypermail 2b29 : Sun Feb 13 2000 - 14:44:04 PST