<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 1 September 2005), see www.w3.org">
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii">
<title>Chapter 13. Configuring TwinView</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.68.1">
<link rel="start" href="index.html" title=
"NVIDIA Accelerated Linux Graphics Driver README and Installation Guide">
<link rel="up" href="installationandconfiguration.html" title=
"Part I. Installation and Configuration Instructions">
<link rel="prev" href="configuringagp.html" title=
"Chapter 12. Configuring AGP">
<link rel="next" href="xineramaglx.html" title=
"Chapter 14. Configuring GLX in Xinerama">
</head>
<body>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<th colspan="3" align="center">Chapter 13. Configuring
TwinView</th>
</tr>
<tr>
<td width="20%" align="left"><a accesskey="p" href=
"configuringagp.html">Prev</a> </td>
<th width="60%" align="center">Part I. Installation and
Configuration Instructions</th>
<td width="20%" align="right"> <a accesskey="n" href=
"xineramaglx.html">Next</a></td>
</tr>
</table>
<hr></div>
<div class="chapter" lang="en">
<div class="titlepage">
<div>
<div>
<h2 class="title"><a name="configtwinview" id=
"configtwinview"></a>Chapter 13. Configuring
TwinView</h2>
</div>
</div>
</div>
<p>TwinView is a mode of operation where two display devices
(digital flat panels, CRTs, and TVs) 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):</p>
<div class="itemizedlist">
<ul type="disc">
<li>
<p>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.</p>
</li>
<li>
<p>Both display devices share one frame buffer. Thus, all the
functionality present on a single display (e.g., accelerated
OpenGL) is available with TwinView.</p>
</li>
<li>
<p>No additional overhead is needed to emulate having a single
desktop.</p>
</li>
</ul>
</div>
<p>If you are interested in using each display device as a separate
X screen, see <a href="configmultxscreens.html" title=
"Chapter 15. Configuring Multiple X Screens on One Card">Chapter 15,
<i>Configuring Multiple X Screens on One Card</i></a>.</p>
<h3>X Configuration TwinView Options</h3>
<p>To enable TwinView, you must specify the following option in the
Device section of your X Config file:</p>
<pre class="screen">
Option "TwinView"
</pre>
<p>You may also use any of the following options, though they are
not required:</p>
<pre class="screen">
Option "MetaModes" "<list of MetaModes>"
Option "SecondMonitorHorizSync" "<hsync range(s)>"
Option "SecondMonitorVertRefresh" "<vrefresh range(s)>"
Option "HorizSync" "<hsync range(s)>"
Option "VertRefresh" "<vrefresh range(s)>"
Option "TwinViewOrientation" "<relationship of head 1 to head 0>"
Option "ConnectedMonitor" "<list of connected display devices>"
</pre>
<p>See detailed descriptions of each option below.</p>
<p>Alternatively, you can enable TwinView by running</p>
<pre class="screen">
nvidia-xconfig --twinview
</pre>
<p>and restarting your X server. Or, you can configure TwinView
dynamically in the "Display Configuration" page in
nvidia-settings.</p>
<h3>Detailed Description of Options</h3>
<div class="variablelist">
<dl>
<dt><span class="term">TwinView</span></dt>
<dd>
<p>This option is required to enable TwinView; without it, all
other TwinView related options are ignored.</p>
</dd>
<dt><span class="term">SecondMonitorHorizSync,</span> <span class=
"term">SecondMonitorVertRefresh</span></dt>
<dd>
<p>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.</p>
<p>These options are normally not needed: by default, the NVIDIA X
driver retrieves the valid frequency ranges from the display
device's EDID (see <a href="xconfigoptions.html" title=
"Appendix B. X Config Options">Appendix B, <i>X
Config Options</i></a> for a description of the "UseEdidFreqs"
option). The SecondMonitor options will override any frequency
ranges retrieved from the EDID.</p>
</dd>
<dt><span class="term">HorizSync,</span> <span class=
"term">VertRefresh</span></dt>
<dd>
<p>Which display device is "first" and which is "second" is often
unclear. For this reason, you may use these options instead of the
SecondMonitor versions. With these options, you can specify a
semicolon-separated list of frequency ranges, each optionally
prepended with a display device name. In addition, if SLI Mosaic
mode is enabled, a GPU specifier can be used. For example:</p>
<pre class="screen">
Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70"
Option "VertRefresh" "CRT-0: 60-120; GPU-0.DFP-0: 60"
</pre>
<p>See <a href="displaydevicenames.html" title=
"Appendix C. Display Device Names">Appendix C,
<i>Display Device Names</i></a> on Display Device Names for more
information.</p>
<p>These options are normally not needed: by default, the NVIDIA X
driver retrieves the valid frequency ranges from the display
device's EDID (see <a href="xconfigoptions.html" title=
"Appendix B. X Config Options">Appendix B, <i>X
Config Options</i></a> for a description of the "UseEdidFreqs"
option). The "HorizSync" and "VertRefresh" options override any
frequency ranges retrieved from the EDID or any frequency ranges
specified with the "SecondMonitorHorizSync" and
"SecondMonitorVertRefresh" options.</p>
</dd>
<dt><a name="metamodes" id="metamodes"></a><span class=
"term">MetaModes</span></dt>
<dd>
<p>MetaModes are "containers" that store information about what
mode should be used on each display device at any given time. Even
if only one display device is actively in use, the NVIDIA X driver
always uses a MetaMode to encapsulate the mode information per
display device, so that it can support dynamically enabling
TwinView.</p>
<p>Multiple MetaModes list the combinations of modes and the
sequence in which they should be used. 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. In MetaMode
syntax, modes within a MetaMode are comma separated, and multiple
MetaModes are separated by semicolons. For example:</p>
<pre class="screen">
"<mode name 0>, <mode name 1>; <mode name 2>, <mode name 3>"
</pre>
<p>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 an example MetaMode:</p>
<pre class="screen">
Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768"
</pre>
<p>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:</p>
<pre class="screen">
"1600x1200, NULL; NULL, 1024x768"
</pre>
<p>or</p>
<pre class="screen">
"1600x1200; , 1024x768"
</pre>
<p>Optionally, mode names can be followed by offset information to
control the positioning of the display devices within the virtual
screen space; e.g.,</p>
<pre class="screen">
"1600x1200 +0+0, 1024x768 +1600+0; ..."
</pre>
<p>Offset descriptions follow the conventions used in the X
"-geometry" command line 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 X config file.</p>
<p>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 single MetaMode, then offsets will be expected for all modes
within that single MetaMode; in such a case offsets will be assumed
to be +0+0 when not given.</p>
<p>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.</p>
<p>A MetaMode string can be further modified with a "Panning
Domain" specification; e.g.,</p>
<pre class="screen">
"1024x768 @1600x1200, 800x600 @1600x1200"
</pre>
<p>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 (i.e., all display devices) will be panned to follow the
mouse within the virtual screen, unless the "PanAllDisplays" X
configuration option is disabled. 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.</p>
<p>The most beneficial use of panning domains is probably to
eliminate dead areas -- regions of the virtual screen that are
inaccessible due to display devices with different resolutions. For
example:</p>
<pre class="screen">
"1600x1200, 1024x768"
</pre>
<p>produces an inaccessible region below the 1024x768 display.
Specifying a panning domain for the second display device:</p>
<pre class="screen">
"1600x1200, 1024x768 @1024x1200"
</pre>
<p>provides access to that dead area by allowing you to pan the
1024x768 viewport up and down in the 1024x1200 panning domain.</p>
<p>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:</p>
<pre class="screen">
"1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200"
</pre>
<p>Because it is often unclear which mode within a MetaMode will be
used on each display device, mode descriptions within a MetaMode
can be prepended with a display device name. For example:</p>
<pre class="screen">
"CRT-0: 1600x1200, DFP-0: 1024x768"
</pre>
<p>If no MetaMode string is specified, then the X driver uses the
modes listed in the relevant "Display" subsection, attempting to
place matching modes on each display device.</p>
<p>Each mode of the MetaMode may also have extra options associated
with it, specified as a comma-separated list of token=value pairs
inside curly brackets. The only token allowed is currently
"Stereo", and the possible values are "PassiveLeft" or
"PassiveRight". When used in conjunction with stereo mode "4", this
allows each display to be configured independently to show any
stereo eye. For example:</p>
<pre class="screen">
"CRT-0: 1600x1200 +0+0 {Stereo = PassiveLeft}, CRT-1: 1600x1200 +1600+0 {Stereo=PassiveRight}"
</pre>
<p>If the X screen is not configured for stereo mode "4", these
options are ignored. See <a href=
"xconfigoptions.html#Stereo"><code class="computeroutput">Option
"Stereo" "integer"</code></a> for more details about stereo
configurations.</p>
</dd>
<dt><span class="term">TwinViewOrientation</span></dt>
<dd>
<p>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:</p>
<pre class="screen">
"RightOf" (the default)
"LeftOf"
"Above"
"Below"
"Clone"
</pre>
<p>When "Clone" is specified, both display devices will be assigned
an offset of 0,0.</p>
<p>Because it is often unclear which display device is "first" and
which is "second", TwinViewOrientation can be confusing. You can
further clarify the TwinViewOrientation with display device names
to indicate which display device is positioned relative to which
display device. For example:</p>
<pre class="screen">
"CRT-0 LeftOf DFP-0"
</pre>
<p></p>
</dd>
<dt><span class="term">ConnectedMonitor</span></dt>
<dd>
<p>With this option you can override what the NVIDIA kernel module
detects is connected to your graphics 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 are a
comma-separated list of display device names; for example:</p>
<pre class="screen">
"CRT-0, CRT-1"
"CRT"
"CRT-1, DFP-0"
</pre>
<p>WARNING: this option overrides what display devices are detected
by the NVIDIA kernel module, and is very seldom needed. You really
only need this if a display device is not detected, either because
it does not provide DDC information, or because it is on the other
side of a KVM (Keyboard-Video-Mouse) switch. In most other cases,
it is best not to specify this option.</p>
</dd>
</dl>
</div>
<p>Just as in all X config entries, spaces are ignored and all
entries are case insensitive.</p>
<h3>Dynamic TwinView</h3>
<p>Using the NV-CONTROL X extension, the display devices in use by
an X screen, the mode pool for each display device, and the
MetaModes for each X screen can be dynamically manipulated. The
"Display Configuration" page in nvidia-settings uses this
functionality to modify the MetaMode list and then uses XRandR to
switch between MetaModes. This gives the ability to dynamically
configure TwinView.</p>
<p>The details of how this works are documented in the
nv-control-dpy.c sample NV-CONTROL client in the nvidia-settings
source tarball.</p>
<p>Because the NVIDIA X driver can now transition into and out of
TwinView dynamically, MetaModes are always used internally by the
NVIDIA X driver, regardless of how many display devices are
currently in use by the X screen and regardless of whether the
TwinView X configuration option was specified.</p>
<p>One implication of this implementation is that each MetaMode
must be uniquely identifiable to the XRandR X extension.
Unfortunately, two MetaModes with the same bounding box will look
the same to XRandR. For example, two MetaModes with different
orientations:</p>
<pre class="screen">
"CRT: 1600x1200 +0+0, DFP: 1600x1200 +1600+0"
"CRT: 1600x1200 +1600+0, DFP: 1600x1200 +0+0"
</pre>
<p>will look identical to the XRandR or XF86VidMode X extensions,
because they have the same total size (3200x1200), and
nvidia-settings would not be able to use XRandR to switch between
these MetaModes. To work around this limitation, the NVIDIA X
driver "lies" about the refresh rate of each MetaMode, using the
refresh rate of the MetaMode as a unique identifier.</p>
<p>The XRandR extension is currently being redesigned by the X.Org
community, so the refresh rate workaround may be removed at some
point in the future. This workaround can also be disabled by
setting the "DynamicTwinView" X configuration option to FALSE,
which will disable NV-CONTROL support for manipulating MetaModes,
but will cause the XRandR and XF86VidMode visible refresh rate to
be accurate.</p>
<div class="qandaset">
<table border="0" summary="Q and A Set">
<col align="left" width="1%">
<tbody>
<tr class="qandadiv">
<td align="left" valign="top" colspan="2"><a name=
"FrequentlyAsked7a5bb" id="FrequentlyAsked7a5bb"></a>
<h3 class="title">13.1. Frequently Asked TwinView Questions</h3>
</td>
</tr>
<tr class="question">
<td align="left" valign="top"><a name="NothingGetsDispcf9c6" id=
"NothingGetsDispcf9c6"></a></td>
<td align="left" valign="top">
<p><b>Nothing gets displayed on my second monitor; what is
wrong?</b></p>
</td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>Monitors that do not support monitor detection using Display
Data Channel (DDC) protocols (this includes most older monitors)
are not detectable by your NVIDIA card. You need to explicitly tell
the NVIDIA X driver what you have connected using the
"ConnectedMonitor" option; e.g.,</p>
<pre class="screen">
Option "ConnectedMonitor" "CRT, CRT"
</pre>
<p></p>
</td>
</tr>
<tr class="question">
<td align="left" valign="top"><a name="WillWindowManag82696" id=
"WillWindowManag82696"></a></td>
<td align="left" valign="top">
<p><b>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)?</b></p>
</td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>Yes. The NVIDIA X driver provides a Xinerama extension that X
clients (such as window managers) can use to discover the current
TwinView configuration. Note that the Xinerama protocol provides no
way to notify clients when a configuration change occurs, so if you
modeswitch to a different MetaMode, your window manager will still
think you have the previous configuration. Using the Xinerama
extension, in conjunction with the XF86VidMode extension to get
modeswitch events, window managers should be able to determine the
TwinView configuration at any given time.</p>
<p>Unfortunately, the data provided by XineramaQueryScreens()
appears to confuse some window managers; to work around such broken
window mangers, you can disable communication of the TwinView
screen layout with the "NoTwinViewXineramaInfo" X config Option
(see <a href="xconfigoptions.html" title=
"Appendix B. X Config Options">Appendix B, <i>X
Config Options</i></a> for details).</p>
<p>The order that display devices are reported in via the TwinView
Xinerama information can be configured with the
TwinViewXineramaInfoOrder X configuration option.</p>
<p>Be aware that the NVIDIA driver cannot provide the Xinerama
extension if the X server's own Xinerama extension is being used.
Explicitly specifying Xinerama in the X config file or on the X
server commandline will prohibit NVIDIA's Xinerama extension from
installing, so make sure that the X server's log file does not
contain:</p>
<pre class="screen">
(++) Xinerama: enabled
</pre>
<p>if you want the NVIDIA driver to be able to provide the Xinerama
extension while in TwinView.</p>
<p>Another solution is to use panning domains to eliminate
inaccessible regions of the virtual screen (see the MetaMode
description above).</p>
<p>A third solution is to use two separate X screens, rather than
use TwinView. See <a href="configmultxscreens.html" title=
"Chapter 15. Configuring Multiple X Screens on One Card">Chapter 15,
<i>Configuring Multiple X Screens on One Card</i></a>.</p>
</td>
</tr>
<tr class="question">
<td align="left" valign="top"><a name="WhyCanINotGetAR43a5f" id=
"WhyCanINotGetAR43a5f"></a></td>
<td align="left" valign="top">
<p><b>Why can I not get a resolution of 1600x1200 on the second
display device when using a GeForce2 MX?</b></p>
</td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>Because the second display device on the GeForce2 MX was
designed to be a digital flat panel, 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). This
constraint is not present on GeForce4 or GeForce FX GPUs -- the
maximum pixel clock is the same on both heads.</p>
</td>
</tr>
<tr class="question">
<td align="left" valign="top"><a name="DoVideoOverlays9b233" id=
"DoVideoOverlays9b233"></a></td>
<td align="left" valign="top">
<p><b>Do video overlays work across both display devices?</b></p>
</td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>Hardware video overlays only work on the first display device.
The current solution is that blitted video is used instead on
TwinView.</p>
</td>
</tr>
<tr class="question">
<td align="left" valign="top"><a name="HowAreVirtualScad03c" id=
"HowAreVirtualScad03c"></a></td>
<td align="left" valign="top">
<p><b>How are virtual screen dimensions determined in
TwinView?</b></p>
</td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>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 panning domains for each MetaMode.
The maximum bounding box width and height is then found.</p>
<p>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:</p>
<pre class="screen">
"1600x1200,NULL; 1024x768+0+0, 1024x768+0+768"
</pre>
<p>the resulting virtual screen size will be 1600 x 1536.</p>
</td>
</tr>
<tr class="question">
<td align="left" valign="top"><a name="CanIPlayFullScr76116" id=
"CanIPlayFullScr76116"></a></td>
<td align="left" valign="top">
<p><b>Can I play full screen games across both display
devices?</b></p>
</td>
</tr>
<tr class="answer">
<td align="left" valign="top"></td>
<td align="left" valign="top">
<p>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:</p>
<pre class="screen">
Option "MetaModes" "1024x768,1024x768; 800x600,800x600"
Option "TwinViewOrientation" "RightOf"
</pre>
<p>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:</p>
<pre class="screen">
seta r_customaspect "1"
seta r_customheight "600"
seta r_customwidth "1600"
seta r_fullscreen "1"
seta r_mode "-1"
</pre>
<p>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:</p>
<pre class="screen">
"800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL"
</pre>
<p>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.</p>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left"><a accesskey="p" href=
"configuringagp.html">Prev</a> </td>
<td width="20%" align="center"><a accesskey="u" href=
"installationandconfiguration.html">Up</a></td>
<td width="40%" align="right"> <a accesskey="n" href=
"xineramaglx.html">Next</a></td>
</tr>
<tr>
<td width="40%" align="left" valign="top">
Chapter 12. Configuring AGP </td>
<td width="20%" align="center"><a accesskey="h" href=
"index.html">Home</a></td>
<td width="40%" align="right" valign="top">
Chapter 14. Configuring GLX in Xinerama</td>
</tr>
</table>
</div>
</body>
</html>
distrib
>
Mageia
>
1
>
i586
>
media
>
nonfree-updates
>
by-pkgid
>
22c40963b0f987706d28066e7c1f9876
>
files
>
10
