Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Thread Tools
Old 03-21-05, 03:51 AM   #1
Registered User
Join Date: Mar 2005
Posts: 10
Default Problem with TwinView

Well, got my new video card yesterday (GeForce FX 5500) and tried to connect my two monitors.

1. TFT monitor from DELL connected with DVI
2. CRT monitor from CTX connected with SUB

However it works fine except my old CRT monitor is still used as the first display. So my taskbar and all the things are displayed on the CRT but not on my DELL one. All I want is to switch that thing to get my TFT the first screen. You can get my xorg.conf here.

As you see I've made two "Device" Sections as well as two "Screen" sections (I've seen that in a tutorial I've found on the web). I've also tried to exchange the monitors names in the "Screen" sections, hoping it would solve my problem. Unfortunately is doesn't. Seems the one connected using SUB is still used as the first display .

Hope someone is able to help me.
Thanks in advance

SinoTech is offline   Reply With Quote
Old 03-21-05, 01:21 PM   #2
Registered User
Join Date: Mar 2005
Posts: 23
Default Re: Problem with TwinView

You only need one device section since it is one card, unless you want two separate X sessions on each display rather than xinerama or a mirror.
This is for Xinerama (one display using both screens) or a mirror which is duplicate of the same screen on both displays.


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, Quadro4, GeForce
FX, or Quadro FX 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

If you are interested in using each display device as a separate
X screen, please see (app-r) APPENDIX R: CONFIGURING MULTIPLE X


To enable TwinView, you must specify the following options in the Device
section of your X Config file:

Option "TwinView"
Option "MetaModes" "<list of metamodes>"

You must also specify either:

Option "SecondMonitorHorizSync" "<hsync range(s)>"
Option "SecondMonitorVertRefresh" "<vrefresh range(s)>"


Option "HorizSync" "<hsync range(s)>"
Option "VertRefresh" "<vrefresh range(s)>"

You may also use any of the following options, though they are not

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 HorizSync, VertRefresh
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. For example:

Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70"
Option "VertRefresh" "CRT-0: 60-120; DFP-0: 60"

Please see the Appendix on Display Device Names for more

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 X config 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"


"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 X config 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

"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"

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:

"CRT-0: 1600x1200, DFP-0: 1024x768"

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)

When "Clone" is specified, both display devices will be assigned
an offset of 0,0.

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:

"CRT-0 LeftOf DFP-0"

o ConnectedMonitor
With this option you can 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 are a comma-separated list of display device names;
for example:

"CRT-0, CRT-1"
"CRT-1, DFP-0"

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.

Just as in all X config entries, spaces are ignored and all entries
are case insensitive.
magneto is offline   Reply With Quote
Old 03-21-05, 01:22 PM   #3
Registered User
Join Date: Mar 2005
Posts: 23
Default Re: Problem with TwinView


Q: Nothing gets displayed on my second monitor; what is wrong?

A: 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.:

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 X clients
(such as window managers) can use 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" X config Option (please see Appendix D
for details).

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:

(++) 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

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.
magneto is offline   Reply With Quote
Old 03-21-05, 03:39 PM   #4
Registered User
Join Date: Mar 2005
Posts: 10
Default Re: Problem with TwinView

Thanks for your reply. Unfortunatelly it doesn't really help me. Currently I've tried it with one single device section (One X session stretched above my two monitors) but the problem is still there (My old CRT is standing on right side of my TFT, but it only displays the left part of my X session and I am unable to exchange them). Anyway I've found another thread about those problem on another board:

But I've got another question about the following statement (Copied from the thread posted above):
I had a similar problem with a nvidia ti4400. After updating the video bios, the tft became primary display.
What do they mean with "updating the video bios" ? Is it just a new driver ? Or is it an update to bios located on graphics card ? And if it's an update to the bios where can get it from ?

So thanks again for your help.

SinoTech is offline   Reply With Quote
Old 03-21-05, 03:49 PM   #5
Registered User
Join Date: Mar 2005
Posts: 23
Default Re: Problem with TwinView

they mean a upgrade to the bios on the video card which you should see displayed when you first turn on your computer and prior to the PC's Bios POST

go to your hardware manufacturer's website

everything in that gentoo post was referenced in that appendix in the nvidia README - a number of those options you had commented out in your xorg.conf
magneto is offline   Reply With Quote
Old 03-21-05, 06:27 PM   #6
Registered User
Join Date: Mar 2005
Posts: 10
Default Re: Problem with TwinView

Oh well I feel so stupid. Thought a BIOS update is only avaiable for your Mainboard but not for other hardware. Anyway, seems there's no one avaible for my card .. . I'll try the other thing posted on the gentoo board tomorrow (the thing with changing the offsets for each screen).

Thanks again for your help

SinoTech is offline   Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
First monitor is black when going to virtual console, when using twinView zeBarbu NVIDIA Linux 2 09-07-03 09:35 PM
XF86Config for a Quadro4 without TwinView? Twirlip NVIDIA Linux 1 10-09-02 10:36 AM
Twinview with TV-out karlaugust NVIDIA Linux 10 08-28-02 04:20 PM
How do I configure TwinView on Dell Inspiron rutgerclaes NVIDIA Linux 6 08-01-02 03:20 AM
Nvidia Go on laptop, black border within XFree86 problem raxip NVIDIA Linux 3 07-31-02 10:58 AM

All times are GMT -5. The time now is 11:42 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.