Gå til innhold

Nvidia Geforce 2 MX400 og S-VIDEO


Anbefalte innlegg

Videoannonse
Annonse

Dette er veldig godt forklart i README som følger med driveren.

 

(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, 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

    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.

 

 

X CONFIG TWINVIEW OPTIONS

 

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

 

or:

 

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

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

 

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

        information.

 

  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"

 

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

        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"

 

        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)

          "LeftOf"

          "Above"

          "Below"

          "Clone"

 

        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"

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

(app-j) APPENDIX J: CONFIGURING TV-OUT

__________________________________________________________________________

 

NVIDIA GPU-based video cards with a TV-Out (S-Video) connector can be

employed to use a television as another display device, just like a CRT

or digital flat panel.  The TV can be used by itself, or (on appropriate

video cards) in conjunction with another display device in a TwinView

configuration.

 

If a TV is the only display device connected to your video card, it will

be used as the primary display when you boot your system (ie the console

will come up on the TV just as if it were a CRT).  To use your TV with X,

there are a few parameters that you should pay special attention to in

your X config file:

 

  o The VertRefresh and HorizSync values in your monitor section;

    please make sure these are appropriate for your television.

    Values are generally:

 

        HorizSync 30-50

        VertRefresh 60

 

  o The Modes in your screen section; the valid modes for your TV encoder

    will be reported in a verbose X log file (generated with `startx --

    -logverbose 5`) when X is run on a TV.  Some modes may be limited

    to certain TV Standards; if that is the case, it will be noted in

    the X log file.  Generally, atleast 800x600 and 640x480 are supported.

 

  o The "TVStandard" option should be added to your screen section; valid

    values are:

 

        "PAL-B"  : used in Belgium, Denmark, Finland, Germany, Guinea,

                  Hong Kong, India, Indonesia, Italy, Malaysia, The

                  Netherlands, Norway, Portugal, Singapore, Spain,

                  Sweden, and Switzerland

        "PAL-D"  : used in China and North Korea

        "PAL-G"  : used in Denmark, Finland, Germany, Italy, Malaysia,

                  The Netherlands, Norway, Portugal, Spain, Sweden,

                  and Switzerland

        "PAL-H"  : used in Belgium

        "PAL-I"  : used in Hong Kong and The United Kingdom

        "PAL-K1" : used in Guinea

        "PAL-M"  : used in Brazil

        "PAL-N"  : used in France, Paraguay, and Uruguay

        "PAL-NC" : used in Argentina

        "NTSC-J" : used in Japan

        "NTSC-M" : used in Canada, Chile, Colombia, Costa Rica, Ecuador,

                  Haiti, Honduras, Mexico, Panama, Puerto Rico, South

                  Korea, Taiwan, United States of America, and Venezuela

        "HD480i" : 480 line interlaced

        "HD480p" : 480 line progressive

        "HD720p" : 720 line progressive

        "HD1080i": 1080 line interlaced

        "HD1080p": 1080 line progressive

        "HD576i" : 576 line interlace

        "HD576p" : 576 line progressive

 

    The line in your X config file should be something like:

 

        Option "TVStandard" "NTSC-M"

 

    If you do not specify a TVStandard, or you specify an invalid value,

    the default "NTSC-M" will be used.  Note: if your country is not in

    the above list, select the country closest to your location.

 

  o The "ConnectedMonitor" option can be used to tell X to use the TV for

    display.  This should only be needed if your TV is not detected by

    the video card, or you use a CRT (or digital flat panel) as your

    boot display, but want to redirect X to use the TV.  The line in

    your config file should be:

 

        Option "ConnectedMonitor" "TV"

 

  o The "TVOutFormat" option can be used to force SVIDEO or COMPOSITE

    output.  Without this option the driver autodetects the output format.

    Unfortunately, it does not always do this correctly.  The output format

    can be forced with the options:

 

        Option "TVOutFormat" "SVIDEO"

 

                    or

 

        Option "TVOutFormat" "COMPOSITE"

 

  o The "TVOverScan" option can be used to enable Overscan where

    supported.  Valid values are decimal values in the range 1.0 (which

    means overscan as much as possible: make the image as large as

    possible) and 0.0 (which means disable overscanning: make the image

    as small as possible).  Overscanning is disabled (0.0) by default.

 

    Overscan is currently only available on GeForce4 or newer GPUs

    with either NVIDIA or Conexant TV encoders.

 

The NVIDIA X driver may not restore the console correctly with XFree86

versions older than 4.3 when the console is a TV.  This is due to binary

incompatibilities between XFree86 int10 modules.  If you use a TV as

your console it is recommended that you upgrade to XFree86 4.3 or later.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...