__________________________________________________________________________
 
(app-i) APPENDIX I: CONFIGURING TWINVIEW
__________________________________________________________________________
 
The TwinView feature is only supported on NVIDIA GPUs that support
dual-display functionality, such as the GeForce2 MX, GeForce2 Go,
Quadro2 MXR, Quadro2 Go, and any of the GeForce4 or Quadro4 GPUs.
Please consult with your video card vendor to confirm that TwinView is
supported on your card.
 
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):
 
  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
    the functionality present on a single display (e.g. accelerated
    OpenGL) is available on TwinView.
 
  o No additional overhead is needed to emulate having a single
    desktop.
 
If you are interested in using each display device as a separate
X screen, please see (app-r)  APPENDIX R: CONFIGURING MULTIPLE X
SCREENS ON ONE CARD.
 
 
XF86CONFIG TWINVIEW OPTIONS
 
To enable TwinView, you must specify the following options in the Device
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:
 
  o TwinView
        This option is required to enable TwinView; without it, all
        other TwinView related options are ignored.
 
  o 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.  You may, if you trust your display devices'
        EDIDs, use the "UseEdidFreqs" option instead of these options
        (see APPENDIX D for a description of the "UseEdidFreqs" option).
 
  o MetaModes
        A single MetaMode describes what mode should be used on each
        display device at a given time.  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:
 
          "<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 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" 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 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 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.
 
        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 further 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 is probably 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"
 
        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.
 
 
  o 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.
 
  o 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), "DFP"
        (digital flat panel), or "TV" (television); 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.
 
 
FREQUENTLY ASKED TWINVIEW 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: Yes.  The NVIDIA X driver provides a Xinerama extension that allows
   X clients (such as window managers) to call XineramaQueryScreens() to
   discover the current TwinView configuration.  Note that the Xinerama
   protocol provides no way to inform clients of 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.
 
   Unfortunately, the data provided by XineramaQueryScreens() appears to
   confuse some window managers; to workaround such broken window mangers,
   you can disable communication of the TwinView screen layout with the
   "NoTwinViewXineramaInfo" XF86Config Option (please see Appendix D
   for details).
 
   Be aware that the NVIDIA driver cannot provide the Xinerama
   extension if XFree86's own Xinerama extension is being used.
   Explicitly specifying Xinerama in the XF86Config file or on the XFree86
   commandline will prohibit NVIDIA's Xinerama extension from installing,
   so make sure that XFree86's /var/log/XFree86.0.log is not reporting:
 
     (++) Xinerama: enabled
 
   if you wish the NVIDIA driver to be able to provide the Xinerama  
   extension while in TwinView.
 
   Another solution is to use panning domains to eliminate inaccessible
   regions of the virtual screen (see the MetaMode description above).
 
   A third solution is to use two separate X screens, rather than use
   TwinView.  Please see (app-r) APPENDIX R: CONFIGURING MULTIPLE X
   SCREENS ON ONE CARD.
 
 
Q: Why can I not get a resolution of 1600x1200 on the second display
   device when using a GeForce2 MX?
 
A: 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 chips -- the maximum pixel clock is the same i
   on both heads.
 
 
Q: Do video overlays work across both display devices?
 
A: Hardware video overlays only work on the first display device.
   The current solution is that blitted video is used instead on TwinView.
 
 
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 panning domains 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 full screen 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.