NVIDIA LINUX TWINVIEW DOCUMENTATION
-----
If you have a GeForce2 MX-based product that supports it, then you
have the option of using TwinView -- a mode of operation where two
display devices (any combination of digital flatpanels and CRTs) can
display the contents of a single X screen in any arbitrary configuration.
This method of multiple monitor use has several distinct advantages over
other techniques (such as Xinerama):
o A single X screen is used -- the NVIDIA driver conceals all
information about multiple display devices from the X server;
as far as X is concerned, there is only one screen.
o Both display devices share one frame buffer; thus all the
things we take for granted on a single display (e.g. accelerated
OpenGL) come for free on TwinView.
o No additional overhead is needed to "fake" having a single
desktop.
Please note that while other boards may have multiple outputs, TwinView
is only supported on GeForce2 MX-based products.
-----
To enable TwinView, you must specify the following options in the Screen
section of your XF86Config(*) file:
Option "TwinView"
Option "SecondMonitorHorizSync" "<hsync range(s)>"
Option "SecondMonitorVertRefresh" "<vrefresh range(s)>"
Option "MetaModes" "<list of metamodes>"
You may also use any of the following options, though they are not
required:
Option "TwinViewOrientation" "<relationship of head 1 to head 0>"
Option "ConnectedMonitor" "<list of connected display devices>"
Please see the detailed descriptions of each option below:
TwinView - This option is required to enable TwinView; without it,
all other TwinView related options are ignored.
SecondMonitorHorizSync, SecondMonitorVertRefresh - You specify the
constraints of the second monitor through these options.
The values given should follow the same convention as the
"HorizSync" and "VertRefresh" entries in the Monitor section.
As the XF86Config man page explains it: the ranges may be a comma
separated list of distinct values and/or ranges of values, where
a range is given by two distinct values separated by a dash.
The HorizSync is given in kHz, and the VertRefresh is given in Hz.
MetaModes - This option is used to describe what mode(s) should be used on
each display device. When the NVIDIA driver tells X what
modes are available, it is really the minimal bounding box of
the MetaMode that is communicated to X, while the "per display
device" mode is kept internal to the NVIDIA driver. The syntax
of a MetaMode is:
"<mode name 0>, <mode name 1>; <mode name 2>, <mode name 3>; ..."
Where <mode name 0> is the name of the mode to be used on display
device 0 concurrently with <mode name 1> used on display device 1.
A mode switch will then cause <mode name 2> to be used on display
device 0 and <mode name 3> to be used on display device 1.
Here is a real MetaMode entry from the XF86Config TwinView sample
config file:
Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768"
If you want a display device to not be active for a certain
MetaMode, you can use the mode name "NULL", or simply omit the
mode name entirely:
"1600x1200, NULL; NULL, 1024x768"
or
"1600x1200; , 1024x768"
Optionally, mode names can be followed by offset information
to control the positioning of the display devices within the
virtual screen space; e.g.:
"1600x1200 +0+0, 1024x768 +1600+0; ..."
Offset descriptions follow the conventions used in the X
"-geometry" commandline option; i.e. both positive and negative
offsets are valid, though negative offsets are only allowed when
a virtual screen size is explicitly given in the XF86Config file.
When no offsets are given for a MetaMode, the offsets will be
computed following the value of the TwinViewOrientation option
(see below). Note that if offsets are given for any one of the
modes in a MetaMode, then offsets will be expected for all modes
within that MetaMode; in such a case offsets will be assumed to
be +0+0 when not given.
When not explicitly given, the virtual screen size will be
computed as the the bounding box of all MetaMode bounding boxes.
MetaModes with a bounding box larger than an explicitly given
virtual screen size will be discarded.
A MetaMode string can be furthed modified with a "Panning Domain"
specification; eg:
"1024x768 @1600x1200, 800x600 @1600x1200"
A panning domain is the area in which a display device's viewport
will be panned to follow the mouse. Panning actually happens on
two levels with TwinView: first, an individual display device's
viewport will be panned within its panning domain, as long as
the viewport is contained by the bounding box of the MetaMode.
Once the mouse leaves the bounding box of the MetaMode, the entire
MetaMode (ie all display devices) will be panned to follow the
mouse within the virtual screen. Note that individual display
devices' panning domains default to being clamped to the position
of the display devices' viewports, thus the default behavior is
just that viewports remain "locked" together and only perform
the second type of panning.
The most beneficial use of panning domains will probably be to
eliminate dead areas -- regions of the virtual screen that are
inaccessible due to display devices with different resolutions.
For example:
"1600x1200, 1024x768"
produces an inaccessible region below the 1024x768
display. Specifying a panning domain for the second display
device:
"1600x1200, 1024x768 @1024x1200"
provides access to that dead area by allowing you to pan the
1024x768 viewport up and down in the 1024x1200 panning domain.
Offsets can be used in conjunction with panning domains to
position the panning domains in the virtual screen space (note
that the offset describes the panning domain, and only affects
the viewport in that the viewport must be contained within the
panning domain). For example, the following describes two modes,
each with a panning domain width of 1900 pixels, and the second
display is positioned below the first:
"1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200"
TwinViewOrientation - This option controls the positioning of the second
display device relative to the first within the virtual X
screen, when offsets are not explicitly given in the MetaModes.
The possible values are:
"RightOf" (the default)
"LeftOf"
"Above"
"Below"
"Clone"
When "Clone" is specified, both display devices will be assigned an
offset of 0,0.
ConnectedMonitor - This option allows you to override what the NVIDIA
kernel module detects is connected to your video card. This may
be useful, for example, if any of your display devices do not
support detection using Display Data Channel (DDC) protocols.
Valid values for this option are "CRT" (cathode ray tube) or
"DFP" (digital flatpanel); when using TwinView, this option may
be a comma-separated list of display devices; e.g.: "CRT, CRT"
or "CRT, DFP".
Just as in all XF86Config entries, spaces are ignored and all entries
are case insensitive.
-----
(*) Note that XFree86 4.0 uses the configuration file "XF86Config-4" if it
exists, so as not to conflict with XFree86 3.x. The file "XF86Config" is
only used by XFree86 4.0 when "XF86Config-4" is not present. Look for the
"(==) Using config file:" line in your XFree86 log file if you are unsure.
-----
FREQUENTLY ASKED QUESTIONS:
Q: Nothing gets displayed on my second monitor; what's wrong?
A: Monitors that do not support monitor detection using Display Data
Channel (DDC) protocols (this includes most older monitors) aren't
detectable by your NVIDIA card. You need to explicitly tell the NVIDIA
XFree86 driver what you have connected using the "ConnectedMonitor"
option; e.g.:
Option "ConnectedMonitor" "CRT, CRT"
Q: Will window managers be able to appropriately place windows
(e.g. avoiding placing windows across both display devices, or in
inaccessible regions of the virtual desktop)?
A: Not exactly. NVIDIA is considering writing an implementation of the
Xinerama extension; this would allow Xinerama-aware window managers to
query the screen layout. The other solution is to use panning domains
to eliminate inaccessible regions of the virtual screen (see the MetaMode
description above).
Q: Why can I not get a resolution of 1600x1200 on the second display
device?
A: Because the second display device was designed to be a digital
flatpanel, the Pixel Clock for the second display device is only 150 MHz.
This effectively limits the resolution on the second display device
to somewhere around 1280x1024 (for a description of how Pixel Clock
frequencies limit the programmable modes, see the XFree86 Video Timings
HOWTO).
Q: Do video overlays work across both display devices?
A: Hardware video overlays only work on the first display device.
The behavior currently seen is that video overlays show up as the
background window color on the second display device. This will be fixed
in a future release, but for the short term, just be sure to run your
video applications on the first display device. In our experiments, we
found that some applications would only use the video overlay if their
window was initially positioned on the first display device. If you
encounter this problem, you can try forcing the window manager to place
the video overlay window on the primary display device through the use
of the "-geometry" commandline option (see the X man page for more on
"-geometry").
Q: How are virtual screen dimensions determined in TwinView?
A: After all requested modes have been validated, and the offsets for each
MetaMode's viewports have been computed, the NVIDIA driver computes the
bounding box of the viewports for each MetaMode. The maximum bounding
box width and height is then found.
Note that one side effect of this is that the virtual width and virtual
height may come from different MetaModes. Given the following MetaMode
string:
"1600x1200,NULL; 1024x768+0+0, 1024x768+0+768"
the resulting virtual screen size will be 1600 x 1536.
Q: Can I play fullscreen games across both display devices?
A: Yes. While the details of configuration will vary from game to game,
the basic idea is that a MetaMode presents X with a mode whose resolution
is the bounding box of the viewports for that MetaMode. For example,
the following:
Option "MetaModes" "1024x768,1024x768; 800x600,800x600"
Option "TwinViewOrientation" "RightOf"
produce two modes: one whose resolution is 2048x768, and another whose
resolution is 1600x600. Games such as Quake 3 Arena use the VidMode
extension to discover the resolutions of the modes currently available.
To configure Quake 3 Arena to use the above MetaMode string, add the
following to your q3config.cfg file:
seta r_customaspect "1"
seta r_customheight "600"
seta r_customwidth "1600"
seta r_fullscreen "1"
seta r_mode "-1"
Note that, given the above configuration, there is no mode with a
resolution of 800x600 (remember that the MetaMode "800x600, 800x600"
has a resolution of 1600x600"), so if you change Quake 3 Arena to use a
resolution of 800x600, it will display in the lower left corner of your
screen, with the rest of the screen grayed out. To have single head modes
available as well, an appropriate MetaMode string might be something like:
"800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL"
More precise configuration information for specific games is beyond the
scope of this document, but the above examples coupled with numerous
online sources should be enough to point you in the right direction.