NVIDIA说明文件翻译计划，请弟兄们多多参与［联手合作共进篇］

北南南北 · 发表于 2002-8-15 01:15:44

编号010
本文档已由quanliking兄弟领译，多谢quanliking兄弟。
弟兄们向您致意！
============================================

编号010
_______________________________________________

(app-d) 附录 D: XF86CONFIG OPTIONS(选项)
_______________________________________________

NVIDIA XFree86 diver 支持以下的驱动选项：

选项 "NvAGP" "integer"

配置 AGP 支持。参数 interger 可在以下选取：
0 ：agp 禁用
1 ：如果可能，使用NVIDIA内部AGP支持
2 ：如果可能，使用AGPGART
3 ：使用任何agp支持（先试用AGPGART，然后试用NVIDIA AGP）

注意NVIDIA内部AGP将支持不能工作，如果AGPGART被静态的编译到内核
或者作为一个模块被建造后被加载到内核（一些发行版在系统引导
时把AGPGART加载到内核）。默认：3 （the default was 1 until after
1.0-1251).

选项 "NoLogo" "boolean"
禁止在X开始的时候显示NVIDIA logo splash屏幕。
默认：显示logo

选项 "NoRenderAccel" "boolean"
使用或禁用RENDER扩展硬件加速。
默认：如果可能的话加速RENDER。

选项 "NoRenderExtension" "boolean"
禁用RENDER扩展。除了重新编译 X-server，XFree86好像没有另外的方法
来禁用此功能。幸运的是，我们能够从驱动中控制这个功能，所以我们提
供这个选项。这个选项对8位色深很有用，这里RENDER通常能获得(steal)
大多数默认的colormap。
默认：可能的话提供RENDER。

选项 "UBB" "boolean"
使用或禁用Unified Back Buffer在任何基于GPUs的Quadro(Quadro4 200/400NVS
除外);
对UBB的描述请看附录 M。
此选项对non-Quadro的芯片无影响。
默认：UBB 对Quadro芯片打开。

选项："WindowFlip" "boolean"
使用或禁用window flipping（窗口翻转，注：此未笔者译，可能不准确），要求UBB已经使用；
对它的描述请看附录 M。如果UBB关闭的话，此选项无影响。它可以提高3D应用程序的性能。
默认：Windos flipping 关闭甚至不论在UBB是否打开。

选项："

ageFlip" "boolean"
使用或禁用page flipping（页面翻转）；对他的描述请看附录 M.
默认：使用page flipping.

选项："DigitalVibrance" "integer"
使用Digital Vibrance Control（数字振动控制）。分为4层：
3，2，1 和 off(0).这个功能只被以下显卡支持：
GeForce2 MX (and 200/400), GeForce2 Go, Quadro2 MXR/EX,
Quadro2 Go, nForce, GeForce3 and Ti variants, Quadro DDC,
and all GeForce4 and Quadro4 variants.
默认：关闭。

选项："Overlay" "boolean"
使用RGB工作站视觉覆盖(workstation overlay visuals，注：此未笔者译，可能不准确).
此选项只有Quadro4芯片组（Quadro4 200/400NVS除外）在24位色深支持。
此选项会导致服务器通知SERVER_OVERLAY_VISUALS根窗口属性，同时GLX将报告
单和双缓冲，Z-buffered 16位 overlay visuals.这个透明键值是象素 0x0000 (hex),
在平面覆盖将没有gamma校正支持。此功能需要XFree86版本4.1.0或更新，
在TwinView模式下不被支持。overlay 只能够在虚拟桌面小于或等于 2046x2047 下使用
（例如它不能在2048x1536模式下工作）。
默认：关闭。

选项 : "SWCursor" "boolean"
使用或禁用X指针的软件渲染。
默认：关闭。

选项："HWCursor" "boolean"
使用或禁用X指针的硬件渲染。
默认：关闭。

选项："CursorShadow" "boolean"
使用或禁用硬件加速指针阴影；这是一个黑色半透明的您的指针形状的复制品
偏离您的真实的指针特定的偏移量。这个选项只在GeForce2 或更好的硬件上可
使用（例如:所有硬件除了TNT/TNT2, GeForce 256, GeForce DDR and
Quadro）。
默认：无指针阴影。

选项："CursorShadowAlpha" "integer"
这个alpha值用来设置指针阴影；只有在CursorShadow打开时可用。这个值必须在
[0，255]范围内 -- 0 是完全透明；255是完全不透明。
默认：64。

选项 "CursorShadowXOffset" "interger"
偏移量，阴影图像将偏移到实际指针的右边，像素计量；只能在CursorShadow
打开下可用。取值范围必须在 [0，32]。
默认：4。

选项 "CursorShadowYOffset" "interger"
偏移量，阴影图像将偏移到实际指针的下方，像素计量；只能在CursorShadow
打开下可用。取值范围必须在 [0，32]。
默认：2。

选项 "ConnectedMonitor" "string"
允许你不用考虑什么NVIDIA内核模块探测正连接到你的视频卡。这个可能很有用，
例如，如果你使用KVM （键盘，视频，鼠标）转换，同时你在X启动后已被转
换。在这种情况下，NVIDIA内核模块不能检测到连接了那一显示设备，NVIDIA
X 驱动会假定你有单一的CRT连接。但是，如果你使用了一台数字平面面板，而不
是CRT的话，在使用这个选项的时候必须明确的告诉NVIDIA X driver连接了什么
显示设备。有效的选项值是 "CRT"（阴极射线管），"DFP"（数字平面面板），
或者 "TV"（电视）；如果使用TwinView,这个选项可以使用逗号分隔的显示设备
列表；例如："CRT,CRT" 或 "CRT,DFP".
默认：字符串为空。

选项 "UseEdidFreqs" "boolean"
这个选项导致 X服务器使用显示设备的EDID中指定的水平和垂直刷新范围（若有的话）。
EDIT提供的范围信息将覆盖Monitor section（监视器部分）指定的水平和垂直刷新范围。
如果显示设备不能提供一个EDID，或EDID不能指定水平或垂直刷新范围，那么X server
经使用Monitor section中默认的水平和垂直刷新范围。

选项 "IgnorEDID" "boolean"
禁止探测你的监视器的EDID（扩展显示鉴定数据）。在模式确认的过程中，被请求的模式
同你的监视器的EDIDs（若有的话）中取得值进行比较。众所周知一些监视器对他们自己
的能力说谎。忽略监视器提供的值可能帮助我们找到可靠的有效模式。但反过来，如果
你不清楚你行为，这是危险的。
默认：使用EDIDs.

选项 "NoDDC" "boolean"
同 "IgnoreEDID"

选项 "FlatPanelProperties" "string"
请求任何已连接的平面面板的特定属性，作为一个用逗号分隔的列表，包括多对property=value。
通常，只有'Scaling' 和 'Dithering' 这两个可行的属性。

可能的值对 'Scaling' 是：
'default' (这个驱动将使用当前使用的任何缩放比例状态），
'native' （这个驱动将使用平面面板的定标器，如果它有的话），
'scaled' （可能的话，这个驱动将使用NVIDIA的定标器），
'centered' （可能的话，这个驱动将使图像居中），
还有 'aspect-scaled'（这个驱动将以NVIDIA的定标器为比例，但保留屏幕高宽比率校正）。

可能的值对 'Dithering' 是：
'default'（此驱动将决定什么时候进行抖动），
'enabled'（此驱动当可能将一直进行抖动），
'disabled'（此驱动从不进行抖动）。
如果没指定任何属性的话，它的值为'default'.
一个属性字符串的样例可能和以下类似：

"Scaling = centered, Dithering = enabled"

选项 "UseInt10Module" "boolean"
使用XFree86 Int10模块来软件引导(soft-boot)所有的二级卡，而不是记录(POSTing)这些卡
通过 NVdriver核心模块。
默认：关闭（POSTing通过NVdriver核心模块完成）。

选项 "TwinView" "boolean"
使用或禁用TwinView.细节请看附录 I.
默认： TwinView 禁用。

选项 "TwinViewOrientation" "string"
当使用TwinView的时候控制两台显示设备的关系。使用以下字符串中的一个：
"RightOf" "LeftOf" "Above" "Below" "Clone".
请看附录 I 中的细节描述。
默认：字符串为空。

选项 "SecondMonitorHorizSync" "range(s)"
这个选项类似Monitor section中的水平条目，但是是针对第二个监视器的，当你使用TwinView.
请看附录 I 中的细节描述。
默认：无。

选项 "SecondMonitorVertRefresh" "range(s)"
这个选项类似Monitor section中的垂直条目，但是是针对第二个监视器的，当你使用TwinView.
请看附录 I 中的细节描述。
默认：无。

选项 "MetaModes" "string"
这个选项描述在每一台显示器上使用混合模式，当你使用TwinView。
请看附录 I 中的细节描述。
默认：字符串为空。

选项 "NoTwinViewXineramaInfo" "boolean"
在TwinView中，NVIDIA X 驱动通常提供了一个 Xinerama 扩展，允许 X 客户端（例如窗口管理器）
调用XineramaQueryScreens()来发现当前的TwinView配置。这混淆了一些窗口管理器，因此提供这个
选项来禁用这个行为。
默认：提供 TwinView Xinerama 信息。

－－－－－－－－－－－－－－－－－－－－－－－
英文原文：

__________________________________________________________________________

(app-d) APPENDIX D: XF86CONFIG OPTIONS
__________________________________________________________________________

The following driver options are supported by the NVIDIA XFree86 driver:

      Option "NvAGP" "integer"
            Configure AGP support. Integer argument can be one of:
            0 : disable agp
            1 : use NVIDIA's internal AGP support, if possible
            2 : use AGPGART, if possible
            3 : use any agp support (try AGPGART, then NVIDIA's AGP)
            Please note that NVIDIA's internal AGP support cannot
            work if AGPGART is either statically compiled into your
            kernel or is built as a module, but loaded into your
            kernel (some distributions load AGPGART into the kernel
            at boot up).  Default: 3 (the default was 1 until after
            1.0-1251).

      Option "NoLogo" "boolean"
            Disable drawing of the NVIDIA logo splash screen at
            X startup.  Default: the logo is drawn.

      Option "NoRenderAccel" "boolean"
            Enable or disable hardware acceleration of the RENDER
            extension.  Default: RENDER is accelerated when possible.

      Option "NoRenderExtension" "boolean"
            Disable the RENDER extension.  Other than recompiling
            the X-server, XFree86 doesn't seem to have another way
            of disabling this.  Fortunatly, we can control this from
            the driver so we export this option.  This is useful in
            depth 8 where RENDER would normally steal most of the
            default colormap. Default: RENDER is offered when possible.

      Option "UBB" "boolean"
            Enable or disable Unified Back Buffer on any Quadro
            based GPUs (Quadro4 200/400NVS excluded);
            please see Appendix M for a description of UBB.
            This option has no affect on non-Quadro chipsets.
            Default: UBB is on for Quadro chipsets.

      Option "WindowFlip" "boolean"
            Enable or disable window flipping when UBB is enabled;
            please see Appendix M for a description.  This has no
            affect when UBB is off.  This may improve performance
            for 3D applications.  Default: Window flipping is off
            by default even when UBB is enabled.

      Option "

ageFlip" "boolean"
            Enable or disable page flipping; please see Appendix M for
            a description.  Default: page flipping is enabled.

      Option "DigitalVibrance" "integer"
            Enables Digital Vibrance Control.  There are 4 levels:
            3, 2, 1 and off (0).  This feature is only supported
            on GeForce2 MX (and 200/400), GeForce2 Go, Quadro2 MXR/EX,
            Quadro2 Go, nForce, GeForce3 and Ti variants, Quadro DDC,
            and all GeForce4 and Quadro4 variants.  Default: off.

      Option "Overlay" "boolean"
            Enables RGB workstation overlay visuals.  This is only
            supported on Quadro4 chips (Quadro4 200/400NVS excluded)
            in depth 24.  This option causes the server to advertise
            the SERVER_OVERLAY_VISUALS root window property and GLX will
            report single and double buffered, Z-buffered 16 bit overlay
            visuals.  The transparency key is pixel 0x0000 (hex).  There
            is no gamma correction support in the overlay plane.  This
            feature requires XFree86 version 4.1.0 or newer, and is not
            supported in TwinView mode.  The overlay can only be used
            with virtual desktops smaller or equal to 2046x2047 (eg. it
            will not work in 2048x1536 modes).
            Default: off.

      Option "SWCursor" "boolean"
            Enable or disable software rendering of the X cursor.
            Default: off.

      Option "HWCursor" "boolean"
            Enable or disable hardware rendering of the X cursor.
            Default: on.

      Option "CursorShadow" "boolean" Enable or disable use of a
            shadow with the hardware accelerated cursor; this is a
            black translucent replica of your cursor shape at a
            given offset from the real cursor.  This option is
            only available on GeForce2 or better hardware (ie
            everything but TNT/TNT2, GeForce 256, GeForce DDR and
            Quadro).  Default: no cursor shadow.

      Option "CursorShadowAlpha" "integer"
            The alpha value to use for the cursor shadow; only
            applicable if CursorShadow is enabled.  This value must
            be in the range [0, 255] -- 0 is completely transparent;
            255 is completely opaque.  Default: 64.

      Option "CursorShadowXOffset" "integer"
            The offset, in pixels, that the shadow image will be
            shifted to the right from the real cursor image; only
            applicable if CursorShadow is enabled.  This value must
            be in the range [0, 32].  Default: 4.

      Option "CursorShadowYOffset" "integer"
            The offset, in pixels, that the shadow image will be
            shifted down from the real cursor image; only applicable
            if CursorShadow is enabled.  This value must be in the
            range [0, 32].  Default: 2.

      Option "ConnectedMonitor" "string"
            Allows you to override what the NVIDIA kernel module
            detects is connected to your video card.  This may
            be useful, for example, if you use a KVM (keyboard,
            video, mouse) switch and you are switched away when
            X is started. In such a situation, the NVIDIA kernel
            module can't detect what display devices are connected,
            and the NVIDIA X driver assumes you have a single CRT
            connected. If, however, you use a digital flat panel
            instead of a CRT, use this option to explicitly tell the
            NVIDIA X driver what is connected. Valid values for this
            option are "CRT" (cathode ray tube), "DFP" (digital flat
            panel), or "TV" (television); if using TwinView, this
            option may be a comma-separated list of display devices;
            e.g.: "CRT, CRT" or "CRT, DFP".  Default: string is NULL.

      Option "UseEdidFreqs" "boolean"
            This option causes the X server to use the HorizSync
            and VertRefresh ranges given in a display device's EDID,
            if any.  EDID provided range information will override
            the HorizSync and VertRefresh ranges specified in the
            Monitor section.  If a display device does not provide an
            EDID, or the EDID doesn't specify an hsync or vrefresh
            range, then the X server will default to the HorizSync
            and VertRefresh ranges specified in the Monitor section.

      Option "IgnoreEDID" "boolean"
            Disable probing of EDID (Extended Display Identification
            Data) from your monitor.  Requested modes are compared
            against values gotten from your monitor EDIDs (if any)
            during mode validation.  Some monitors are known to lie
            about their own capabilities.  Ignoring the values that
            the monitor gives may help get a certain mode validated.
            On the other hand, this may be dangerous if you don't
            know what you are doing.  Default: Use EDIDs.

      Option "NoDDC" "boolean"
            Synonym for "IgnoreEDID"

      Option "FlatPanelProperties" "string"
            Requests particular properties of any connected flat
            panels as a comma-separated list of property=value pairs.
            Currently, the only two available properties are 'Scaling'
            and 'Dithering'. The possible values for 'Scaling' are:
            'default' (the driver will use whatever scaling state
            is current), 'native' (the driver will use the flat
            panel's scaler, if it has one), 'scaled' (the driver
            will use the NVIDIA scaler, if possible), 'centered'
            (the driver will center the image, if possible),
            and 'aspect-scaled' (the driver will scale with the
            NVIDIA scaler, but keep the aspect ratio correct).
            The possible values for 'Dithering' are: 'default'
            (the driver will decide when to dither), 'enabled' (the
            driver will always dither when possible), and 'disabled'
            (the driver will never dither).  If any property is not
            specified, it's value shall be 'default'.  An example
            properties string might look like:

            "Scaling = centered, Dithering = enabled"

      Option "UseInt10Module" "boolean"
            Enable use of the XFree86 Int10 module to soft-boot all
            secondary cards, rather than POSTing the cards through
            the NVdriver kernel module.  Default: off (POSTing is
            done through the NVdriver kernel module).

      Option "TwinView" "boolean"
            Enable or disable TwinView.  Please see APPENDIX I for
            details. Default: TwinView is disabled.

      Option "TwinViewOrientation" "string"
            Controls the relationship between the two display devices
            when using TwinView.  Takes one of the following values:
            "RightOf" "LeftOf" "Above" "Below" "Clone".  Please see
            APPENDIX I for details. Default: string is NULL.

      Option "SecondMonitorHorizSync" "range(s)"
            This option is like the HorizSync entry in the Monitor
            section, but is for the second monitor when using
            TwinView.  Please see APPENDIX I for details. Default:
            none.

      Option "SecondMonitorVertRefresh" "range(s)"
            This option is like the VertRefresh entry in the Monitor
            section, but is for the second monitor when using
            TwinView.  Please see APPENDIX I for details. Default:
            none.

      Option "MetaModes" "string"
            This option describes the combination of modes to use
            on each monitor when using TwinView. Please see APPENDIX
            I for details. Default: string is NULL.

      Option "NoTwinViewXineramaInfo" "boolean"
            When in TwinView, the NVIDIA X driver normally provides a
            Xinerama extension that allows X clients (such as window
            managers) to call XineramaQueryScreens() to discover
            the current TwinView configuration.  This confuses some
            window mangers, so this option is provided to disable
            this behavior.  Default: TwinView Xinerama information
            is provided.

北南南北 · 发表于 2002-8-15 01:18:50

编号011
本文档已由quanliking兄弟领译，多谢quanliking兄弟。
弟兄们向您致意！
============================================

编号011
________________________________________________________
(app-e) APPENDIX E: OPENGL ENVIRONMENT VARIABLE SETTINGS
________________________________________________________
(app-e) 附录 E ：OPENGL 环境变量的设置

FULL SCENE ANTI-ALIASING （全屏反锯齿）

反锯齿是一项技术用来光滑屏幕中物体的边缘来减少有时候会出现的锯齿状的阶梯效果

。全屏反锯齿被GeForce或更新的硬件所支持。通过设置相应的环境变量，让你能够基于

这些GPUS在任何的OpenGl应用程序中使用全屏反锯齿。

几种反锯齿方法可行，同时你能够在它们之间进行选择通过设置相应的环境变量

__GL_FSAA_MODE.注意在FSAA渲染的过程中增加取样数目会使性能下降。

以下的表格描述了可能的值提供给 __GL_FSAA_MODE 以及它们对各种NVIDIA GPUs造成的

结果。

__GL_FSAA_MODE GeForce, GeForce2, Quadro, and Quadro2 Pro
-----------------------------------------------------------------------
0 FSAA disabled
1 FSAA disabled
2 FSAA disabled
3 1.5 x 1.5 Supersampling
4 2 x 2 Supersampling
5 FSAA disabled

__GL_FSAA_MODE GeForce4 MX, Quadro4 500/550 XGL, and
Quadro4 200/400 NVS
-----------------------------------------------------------------------
0 FSAA disabled
1 2x Bilinear Multisampling
2 2x Quincunx Multisampling
3 FSAA disabled
4 2 x 2 Supersampling
5 FSAA disabled

__GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, Quadro4 700 XGL,
Quadro4 750 XGL, and Quadro4 900 XGL
-----------------------------------------------------------------------
0 FSAA disabled
1 2x Bilinear Multisampling
2 2x Quincunx Multisampling
3 FSAA disabled
4 4x Bilinear Multisampling
5 4x Gaussian Multisampling

请注意在Quadro家族产品上使用FSAA，你必须禁用UBB （请看附录 M: PAGE FLIPPING,

WINDOW FLIPPING, AND UBB for details).

ANISOTROPIC TEXTURE FILTERING（非等方性的纹理过滤）

自动启用非等方性的纹理过滤通过设置环境变量 __GL_DEFAULT_LOG_ANISO，有用的值：

__GL_DEFAULT_LOG_ANISO GeForce/GeForce2/GeForce4 MX Description
-----------------------------------------------------------------------
0 No anisotropic filtering（无非等方性的纹理过滤）
1 Enable automatic anisotropic filtering（启用）

__GL_DEFAULT_LOG_ANISO GeForce3/GeForce4 Ti Description
-----------------------------------------------------------------------
0 No anisotropic filtering（无）
1 Low anisotropic filtering（低）
2 Medium anisotropic filtering（中）

VBLANK SYNCING （VBLANK 同步）

设置环境变量 __GL_SYNC_TO_VBLANK 为一非零值将强迫glXSwapBuffers来同步你监视器

的垂直刷新率（值在垂直空白期执行一次交换）。对GeForce 或更新的硬件（例如：任

何硬件除了TNT/TNT2产品）。

3 Maximum anisotropic filtering （最大）

－－－－－－－－－－－－－－－－－－－－－－－
英文原文：

__________________________________________________________________________

(app-e) APPENDIX E: OPENGL ENVIRONMENT VARIABLE SETTINGS
__________________________________________________________________________

FULL SCENE ANTI-ALIASING

Anti-aliasing is a technique used to smooth the edges of objects in a
scene to reduce the jagged "stairstep" effect that sometimes appears.
Full scene anti-aliasing is supported on GeForce or newer hardware.
By setting the appropriate environment variable, you can enable full
scene anti-aliasing in any OpenGL application on these GPUs.

Several anti-aliasing methods are available and you can select between
them by setting the __GL_FSAA_MODE environment variable appropriately.
Note that increasing the number of samples taken during FSAA rendering
may decrease performance.

The following tables describe the possible values for __GL_FSAA_MODE
and their effect on various NVIDIA GPUs.

__GL_FSAA_MODE  GeForce, GeForce2, Quadro, and Quadro2 Pro
-----------------------------------------------------------------------
  0          FSAA disabled
  1          FSAA disabled
  2          FSAA disabled
  3          1.5 x 1.5 Supersampling
  4          2 x 2 Supersampling
  5          FSAA disabled

__GL_FSAA_MODE  GeForce4 MX, Quadro4 500/550 XGL, and
            Quadro4 200/400 NVS
-----------------------------------------------------------------------
  0          FSAA disabled
  1          2x Bilinear Multisampling
  2          2x Quincunx Multisampling
  3          FSAA disabled
  4          2 x 2 Supersampling
  5          FSAA disabled

__GL_FSAA_MODE  GeForce3, Quadro DCC, GeForce4 Ti, Quadro4 700 XGL,
            Quadro4 750 XGL, and Quadro4 900 XGL
-----------------------------------------------------------------------
  0          FSAA disabled
  1          2x Bilinear Multisampling
  2          2x Quincunx Multisampling
  3          FSAA disabled
  4          4x Bilinear Multisampling
  5          4x Gaussian Multisampling

Please note that to use FSAA on Quadro-family products, you must disable
UBB (please see APPENDIX M: PAGE FLIPPING, WINDOW FLIPPING, AND UBB
for details).

ANISOTROPIC TEXTURE FILTERING

Automatic anisotropic texture filtering can be enabled by setting
the environment variable __GL_DEFAULT_LOG_ANISO,  The useful values
are:

__GL_DEFAULT_LOG_ANISO  GeForce/GeForce2/GeForce4 MX Description
-----------------------------------------------------------------------
  0    No anisotropic filtering
  1    Enable automatic anisotropic filtering

__GL_DEFAULT_LOG_ANISO  GeForce3/GeForce4 Ti Description
-----------------------------------------------------------------------
  0    No anisotropic filtering
  1    Low anisotropic filtering
  2    Medium anisotropic filtering
  3    Maximum anisotropic filtering

VBLANK SYNCING

Setting the environment variable __GL_SYNC_TO_VBLANK to a non-zero value
will force glXSwapBuffers to sync to your monitor's vertical refresh rate
(perform a swap only during the vertical blanking period) on GeForce or
newer hardware (ie: everything but TNT/TNT2 products).

北南南北 · 发表于 2002-8-15 01:19:38

编号012
本文档已由quanliking兄弟领译，多谢quanliking兄弟。
弟兄们向您致意！
============================================

编号012
__________________________________________________________________________

(app-f) APPENDIX F: CONFIGURING AGP
__________________________________________________________________________
(app-f) 附录 F : 配置 AGP

在配置NVdriver内核驱动中使用AGP有几个选择：
你能选择使用NVIDIA的AGP模块(NVAGP),或者使用linux内核提供的AGP模块(AGPGART).可以在你的XF86Config文

件中通过"NvAGP"选向来控制：

Option "NvAgp" "0" ... disables AGP support
Option "NvAgp" "1" ... use NVAGP, if possible
Option "NvAgp" "2" ... use AGPGART, if possible
Option "NvAGP" "3" ... try AGPGART; if that fails, try NVAGP

默认是3(the default was 1 until after 1.0-1251).

你应该使用和你的AGP芯片组配合的最好的AGP模块。
如果你在稳定性上碰到问题的话，你想要启动的话，可以通过禁用AGP来观察是否这样能解决问题。然后你能够

试验其他的AGP模块。

你能够在任何时间询问当前的AGP状态，通过/proc文件系统界面（参阅附录O： PROC INTERFACE）。

为了使用Linux AGPGART模块，它需要被编译到你的内核，或者作一个静态连接，也可以作为一个模块来建造。

如果AGPGART已经被加载到内核，NVIDIA AGP支持将不能被使用。当你试着使用NVIDIA AGP的时候，建议你编译

AGPGART为一个模块，确信它没有被加载。请注意改变了AGP驱动后，通常需要重起系统使改变生效。

以下的AGP芯片被NVIDIA的AGP支持；对于所有其它的芯片，建议你使用AGPGART模块。

o Intel 440LX
o Intel 440BX
o Intel 440GX
o Intel 815 ("Solano")
o Intel 820 ("Camino")
o Intel 840 ("Carmel")
o Intel 845 ("Brookdale")
o Intel 850 ("Tehama")
o Intel 860 ("Colusa")
o AMD 751 ("Irongate")
o AMD 761 ("IGD4")
o AMD 762 ("IGD4 MP")
o VIA 8371
o VIA 82C694X
o VIA KT133
o VIA KT266
o RCC 6585HE
o Micron SAMDDR ("Samurai")
o Micron SCIDDR ("Scimitar")
o nForce AGP
o ALi 1621
o ALi 1631
o ALi 1647
o ALi 1651
o ALi 1671
o SiS 630
o SiS 633
o SiS 635
o SiS 645
o SiS 730
o SiS 733
o SiS 735
o SiS 745

如果你经历了AGP稳定性问题的话，你应该清楚以下内容：

o Support for the processor's Page Size Extension on Athlon Processors
(o 在 Athlon 处理器上支持处理器页面尺寸扩展)

和使用基于 Windows 2000 的操作系统相似，你的Linux 系统可能会停止反应，如果你运行的应用程序着重于

AGP（例如 ViewPerf）。这个问题通常被解决通过传递"mem=nopentium"选项到linux内核，这样就禁用了

processor's Page Size Extension支持。可能这样会影响一些应用程序的性能。进一步的细节，参阅

Microsoft Knowledge Base Article Q270715.

o AGP drive strength BIOS setting (Via based mainboards)

许多威盛芯片的主板允许在系统BIOS调整AGP drive strength 。这个选项的设置严重的影响了系统的稳定性，

对NVIDIA硬件来说在OxEA和OxEE范围内工作的最好。设置任何一点点超过OxF通常会导致严重的稳定性问题。

如果你决定试验的话，你必须清楚实际，你正在冒险，可能不正确的设置会使你的系统不可引导，除非你重新

设置一个可工作的值（w/ a PCI graphics card 或恢复BIOS到默认值）。

o System BIOS version

确信使用了主板厂商提供的最新的系统BIOS.

o AGP Fast Writes

这个AGP功能可能导致严重的稳定性问题。它能够在许多系统BIOS中启用/禁用。如果你的BIOS不提供这个选项

，你也可以强迫AGP快写关闭，通过设置 NVreg_EnableAGPFW NVdriver 模块参数。

如果你插入模块手动：

insmod NVdriver NVreg_EnableAGPFW=0

如果你使用modprobe (/etc/modules.conf):

alias char-major-195 NVdriver
options NVdriver NVreg_EnableAGPFW=0

o AGP Rate

如果你可能被当前使用的值锁住，你可能想减少AGP rate 设置。你能通过
NVreg_ReqAGPRate NVdriver 模块参数进行设置。

如果你手动插入模块：

insmod NVdriver NVreg_ReqAGPRate=2 # force AGP Rate to 2x
insmod NVdriver NVreg_ReqAGPRate=1 # force AGP Rate to 1x

如果你使用modprobe (/etc/modules.conf):

alias char-major-195 NVdriver
options NVdriver NVreg_ReqAGPRate=2 # force AGP Rate to 2x
options NVdriver NVreg_ReqAGPRate=1 # force AGP Rate to 1x

在使用VIA KX133 or 694X 芯片的Athlon主板，比如ASUS K7V主板，NVIDIA驱动默认为AGP 2x模式，来解决不

能给一些信号提供足够的驱动力问题。你可以强迫AGP 4x，
通过设置NVreg_EnableVia4x 为1。注意这样可能导致系统不稳定。

对于ALi1541和ALi1647芯片，NVIDIA驱动禁用AGP来解决时间问题和信号完整性问题。你
能够强迫在这些芯片上使用AGP,通过设置NVreg_EnableALiAGP为1。
注意这样可能会导致系统不稳定。

－－－－－－－－－－－－－－－－－－－－－－－
英文原文：

__________________________________________________________________________

(app-f) APPENDIX F: CONFIGURING AGP
__________________________________________________________________________

There are several choices for configuring the NVdriver kernel module's
use of AGP: you can choose to either use NVIDIA's AGP module (NVAGP),
or the AGP module that comes with the linux kernel (AGPGART).  This is
controlled through the "NvAGP" option in your XF86Config file:

      Option "NvAgp" "0"  ... disables AGP support
      Option "NvAgp" "1"  ... use NVAGP, if possible
      Option "NvAgp" "2"  ... use AGPGART, if possible
      Option "NvAGP" "3"  ... try AGPGART; if that fails, try NVAGP

The default is 3 (the default was 1 until after 1.0-1251).

You should use the AGP module that works best with your AGP chip set.
If you are experiencing problems with stability, you may want to start
by disabling AGP and observing if that solves the problems.  Then you
can experiment with either of the other AGP modules.

You can query the current AGP status at any time via the /proc filesystem
interface (see APPENDIX O: PROC INTERFACE).

To use the Linux AGPGART module, it will need to be compiled with
your kernel, either statically linked in, or built as a module.
NVIDIA AGP support cannot be used if AGPGART is loaded in the kernel.
It's recommended that you compile AGPGART as a module and make sure that
it is not loaded when trying to use NVIDIA AGP.

Please also note that changing AGP drivers generally requires a reboot
before the changes actually take effect.

The following AGP chipsets are supported by NVIDIA's AGP; for all other
chipsets it's recommended that you use the AGPGART module.

  o Intel 440LX
  o Intel 440BX
  o Intel 440GX
  o Intel 815 ("Solano")
  o Intel 820 ("Camino")
  o Intel 840 ("Carmel")
  o Intel 845 ("Brookdale")
  o Intel 850 ("Tehama")
  o Intel 860 ("Colusa")
  o AMD 751 ("Irongate")
  o AMD 761 ("IGD4")
  o AMD 762 ("IGD4 MP")
  o VIA 8371
  o VIA 82C694X
  o VIA KT133
  o VIA KT266
  o RCC 6585HE
  o Micron SAMDDR ("Samurai")
  o Micron SCIDDR ("Scimitar")
  o nForce AGP
  o ALi 1621
  o ALi 1631
  o ALi 1647
  o ALi 1651
  o ALi 1671
  o SiS 630
  o SiS 633
  o SiS 635
  o SiS 645
  o SiS 730
  o SiS 733
  o SiS 735
  o SiS 745

If you are experiencing AGP stability problems, you should be aware of
the following:

  o Support for the processor's Page Size Extension on Athlon Processors

Similar to systems using Windows 2000 based operating systems, your
Linux system may stop responding if you use applications that stress
AGP (such as ViewPerf). This can often be solved by passing the
"mem=nopentium" option to the Linux kernel, which disables support
for the processor's Page Size Extension.  This may impact performance
with some applications.  For further details, see Microsoft Knowledge
Base Article Q270715.

  o AGP drive strength BIOS setting (Via based mainboards)

Many Via based mainboards allow adjusting the AGP drive strength in
the system BIOS. The setting of this option largely affects system
stability, the range between 0xEA and 0xEE seems to work best for
NVIDIA hardware. Setting either nibble to 0xF generally restults in
severe stability problems.

If you decide to experiment with this, you need to be aware of
the fact that you are doing so at your own risk and that you may
render your system unbootable with improper settings until you
reset the setting to a working value (w/ a PCI graphics card or
by resetting the BIOS to its default values).

  o System BIOS version

Make sure to have the latest system BIOS provided by the board
manufacturer.

  o AGP Fast Writes

This AGP feature may cause severe stability problems. It can be
en/disabled in many system BIOSes.  If your BIOS does not offer
this option, you can force support for AGP Fast Writes off with the
NVreg_EnableAGPFW NVdriver module parameter.

If you are inserting the module manually:

   insmod NVdriver NVreg_EnableAGPFW=0

If you are using modprobe (/etc/modules.conf):

   alias char-major-195 NVdriver
   options NVdriver NVreg_EnableAGPFW=0

  o AGP Rate

You may want to decrease the AGP rate setting if you are seeing
lockups with the value you are currently using. You can do so
with the NVreg_ReqAGPRate NVdriver module parameter.

If you are inserting the module manually:

   insmod NVdriver NVreg_ReqAGPRate=2 # force AGP Rate to 2x
   insmod NVdriver NVreg_ReqAGPRate=1 # force AGP Rate to 1x

If you are using modprobe (/etc/modules.conf):

   alias char-major-195 NVdriver
   options NVdriver NVreg_ReqAGPRate=2  # force AGP Rate to 2x
   options NVdriver NVreg_ReqAGPRate=1  # force AGP Rate to 1x

On Athlon motherboards with the VIA KX133 or 694X chip set, such as the
ASUS K7V motherboard, NVIDIA drivers default to AGP 2x mode to work around
insufficient drive strength on one of the signals.  You can force AGP 4x
by setting NVreg_EnableVia4x to 1.  Note that this may cause the system
to become unstable.

On ALi1541 and ALi1647 chipsets, NVIDIA drivers disable AGP to work
around timing issues and signal integrity issues. You can force AGP
to be enabled on these chipsets by setting NVreg_EnableALiAGP to 1.
Note that this may cause the system to become unstable.

北南南北 · 发表于 2002-8-15 01:20:21

编号013
本文档目前没有弟兄来认领，请高手兄弟出手，多谢
============================================

__________________________________________________________________________

(app-g) APPENDIX G: ALI SPECIFIC ISSUES
__________________________________________________________________________

The following tips may help stabilize problematic ALI systems:

  o Disable TURBO AGP MODE in the BIOS.

  o When using a P5A upgrade to BIOS Revision 1002 BETA 2.

  o When using 1007, 1007A or 1009 adjust the IO Recovery Time to
4 cycles.

  o AGP is disabled by default on some ALi chipsets (ALi1541, ALi1647)
to work around severe system stability problems with these chipsets.
See the comments for NVreg_EnableALiAGP in os-registry.c to force
AGP on anyway.

__________________________________________________________________________

(app-h) APPENDIX H: TNT SPECIFIC ISSUES
__________________________________________________________________________

Most issues pertaining to SGRAM/SDRAM TNT cards should be resolved.
There is the rare chance, however, that your video card has the wrong
BIOS installed, and that this driver will continue to fail for you.

If this driver fails for you, do the following:

  o watch your monitor as the system boots. The very first, brief screen
will identify the type of video memory your card has. This will be
either SGRAM or SDRAM.

  o get the most recent NVIDIA_kernel tar file

  o edit the file "os-registry.c" from the kernel module sources.  Look
for the variable "NVreg_VideoMemoryTypeOverride".  Set the value of
the variable to the type of memory you have (numerically, see the
line just above it).

  o since we don't normally use this variable, change the "#if 0" that is
about 10 lines above the variable to "#if 1".

  o rebuild and reinstall the new driver ("make")

__________________________________________________________________________

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

XF86CONFIG TWINVIEW OPTIONS

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:

  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 "

anning 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).

Another 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 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 chips -- the maximum pixel clock is the same 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.

北南南北 · 发表于 2002-8-15 01:20:53

编号014
本文档已由coco兄弟领译，多谢coco兄弟。
弟兄们向您致意！
============================================

编号014
__________________________________________________________________________

（ app-j ) 附录 J ：设置 TV-OUT
__________________________________________________________________________

通过一台电视机,NVIDIA GPU-based(基于GPU) 的显卡与TV-Out (S-Video) 接头能够被
用于其他的显示设备, 就象一个 CRT 或数字化的平台嵌板
。电视能够自己单独使用, 或(在适当的显卡上) 与用
TwinView 配置的另外的显示设备一起使用。

如果你的电视是唯一与你的显卡相连接的显示设备, 当你启动你的系统的时候
，它将被作为主要的显示供你的系统使用( 即就在电视上被来好像
它是一 CRT 的控制台愿望 ) 。在X视窗下使用电视作为输出设备, 在XF86Config
文件里有一些参数你应该给予特殊的注意：

o 在你的配置文件里监视器设置部分的 VertRefresh 和 HorizSync 值;请保证这些设置
与你的电视是相附和的。值通常是：

HorizSync 30-50
VertRefresh 60

o 在你的屏幕设置部分里的模式节;对于电视的唯一的有效的模式是 640x480 和
800x600 , 如果在你的显卡上的电视编码器是一个BrookTree 871的,有效的模式也可能是 1024x768
--你的 XFree86 记录文件应该告诉你你有什
么编码器 ( 寻找行："(--) NVIDIA ( 0 ) ：电视编码器检测了 TV Encoder detected as") 。

o 选择应该被加到你的屏幕设置部分的" TVStandard ";有效的值是：

" PAL-B "：在比利时，丹麦，芬兰，德国，畿尼，香港，印度，印度尼西亚，意大利，马来西亚荷兰挪威葡萄牙新加坡西班牙瑞典和瑞士使用比较普遍
" PAL-D " :在中国和北朝鲜使用比较普遍
" PAL-G "：在丹麦，芬兰，德国，意大利，马来西亚，荷兰，挪威，葡萄牙，西班牙，瑞典并且瑞士使用比较普遍
" PAL-H " :在比利时使用比较普遍
" PAL-I "：在香港和英国使用比较普遍
" PAL-K1 "：在畿尼使用比较普遍
" PAL-M "：在巴西使用比较普遍
" PAL-N "：在法国，巴拉圭，和乌拉圭使用比较普遍
" PAL-NC "：在阿根廷使用比较普遍
" NTSC-J "：在日本使用比较普遍
" NTSC-M "：在加拿大，智利，哥伦比亚，哥斯达黎加， Ecuador ， Haiti ， Honduras ，墨西哥，巴拿马，波多黎哥南朝鲜台湾美国并且委内瑞拉使用比较普遍

在你的 XF86Config 文件的行应该是一些东西象一样：

Option " TVStandard " " NTSC-M "

如果你不指定一个 TVStandard ，或你指定一个无效的值, 将
使用缺省的"NTSC-M"。注意：如果你的国家不在上面的列表内，请选择离你国家最近的邻国。

o " ConnectedMonitor "选项将告诉你的X视窗用TV来作为显示设备。
仅仅当你的电视没有被你的显卡检测到，又或者你使用一个
CRT (或数字的平台嵌板) 作为你的引导区显示，但是想要重
定向 X 使用电视。有关这项的设置在你的配置文件里应该是如下这样：

Option "ConnectedMonitor" "TV"

o" TVOutFormat "这个选项经常用于强迫使用SVIDEO或COMPOSITE输出。
输出格式可以被强制设定为如下：

Option " TVOutFormat " " SVIDEO "

或

Option " TVOutFormat " " COMPOSITE "

__________________________________________________________________________

（ app-k ) 附录 K ：设置一台便携式计算机(笔记本)
__________________________________________________________________________

安装和配置

在笔记本电脑上NVIDIA的Accelerated Linux驱动的安装和设置和在台式计算机上基本是一样的
, 仅仅有一些微小的差别，下面列出了这些微小的差别。

就从1.0-2802 版本开始介绍, 关于在初始化显示时所使用的内部的flatpanel
的由即时地从在影象被默认的产生在存储在显卡BIOS中的数据库。
这个能通过向" SoftEDIDs "内核选项发送0来停用。如果" SoftEDIDs "
被关掉，然后硬件数据将从一张表格中选择，基于"Mobile"内核选
择的值。

"Mobile"内核选项可以被设置为任意一种下面的值：

0xFFFFFFFF ：让内核模块自动检测正确的值
1 : Dell laptops
2 : non-Compal Toshiba laptops
3 : all other laptops
4 : Compal Toshiba laptops
5 : Gateway laptops

再,"Mobile"的内核选项仅仅当SoftEDIDs被停用的时候才被需要;当它被
使用时，让内核模块自动检测正确的值，通常是最安全的 ( 这是缺省
行为 ) 。

假如你想改变选项中的任何一个, 可以按照一下的步骤进行：

o 在 NVIDIA_kernel 包里编辑 os-registry.c

o 将值设置在 modprobe 命令行上 ( 例如：" modprobe NVdriver
NVreg_SoftEDIDs=0 NVreg_Mobile=3' ）

o 增加一个"Option"行到你的模块的配置文件, 通常是 /etc/modules.conf
( 例如："Option NVdriver NVreg_Mobile=5 ")

附加的功能

TWINVIEW

所有mobile NVIDIA 芯片都支持 TwinView 。在一台笔记本计算机上设置
TwinView 和在一台台式机上设置TwinView基本上是一样的( 请参考上面的
附录I );注意当一个 TwinView 配置使用笔记本计算机的内部的平台嵌板和一个外部的
CRT 的时候， CRT 是主要的显示设备 (指定它是
在你的 XF86Config 文件的监视器部分的 HorizSync 和 VertRefresh节中)
并且平台嵌板是处于第二地位的显示设备 ( 指定它通过
SecondMonitorHorizSync 和 SecondMonitorVertRefresh 选项的
HorizSync 和 VertRefresh节中) 。你也可以利用 UseEdidFreqs 选项从
每台显示设备的 EDID 获得 HorizSync 和 VertRefresh ，并且别担
心将它们设置在你的 XF86Config 文件里面会出现什么问题 ( 如果你信任你的显示设备的
报导的 EDIDs ，那么就请用这个来设置你的XF86Config吧--请阅读附录 D 以获取有关
UseEdidFreqs 选择的详细描述 ) 。

显示设备的热键转接

除 TwinView 以外，活动的 NVIDIA 芯片也有能力觉察到一个
LCD/CRT 热键事件，
触发器在每一个联接的显示器设备之间和可能合并的联接在一起的显示器设备之间

( 注意那仅仅是2个显示设备可以是同时活跃的
) 。当在你的 XF86Config 设置了TwinView ，文件和热键功能是
互相独占的--如果你在你的 XF86Config 文件启用 TwinView ，那么
NVIDIA X 驱动程序将忽略 LCD/CRT 热键事件。

热键功能的另外的重要的方面是使你能够动态地联接并且移开显示设备
从你的笔记本到他人的笔记本或从他人的笔记本到你的笔记本而没必要重启 X 。

有了这项功能后你将担心的是怎么样确定和决定在每台显示设备上规划什么样的模式
。首先, 使用 UseEdidFreqs 是极其有用的,以便为每台显
示设备的 hsync 和 vrefresh 能从显示设备的 EDID 上被检索--否则，
监视器设置部分的内容的语义常常因为热键事件而改变。

当 X 被启动时，或当在显示设备的连接清单上监测到一个变化时，一
张新热键顺序表被构造--将使用显示设备的这张表在每个热键事件上。
当一个热键事件发生时，然后在顺序的下一个热键状态被选择。XF86Config设置文件里
所许要的每一个模式是由显示设备的限制所决定，最后决定的模式必需于
显示设备相适应。如果多种的显示设备
马上激活，那么每台显示设备的模式将一起被配对;如果不能准确的匹
配 ( 同样的分辨率 ) , 那么被找到的将是离它最近的那一个分辨率，
被找到的那个分辨率将被改变以适合其他的更小分辨率的显示设备。

当vt-switching退出X的时候 , 当X被启动的时候 vga 控制台将总是在显示设备上立即被恢复。
同样的, 当vt-switching再次进入 X 的时候,
一样的显示设备配置也将被用于你的 vt-switching 离开 X 的时候，
当vt-switching离开时,不关LCD/CRT热键发生什么活动都将不与考虑。

在 LCD 显示上的非标准的模式

一些用户在规划一个 1400x1050 模式的时候将有一些困难( 一些笔记本计算机
LCDs 的本国的分辨率 ) 。在版本 4.0.3 ， XFree86 把若干
1400x1050 模式增加到它的缺省模式数据库, 但是如果你正在使用
XFree86 的一个更旧的版本，在这里是你能使用的数据行：

#-- 1400x1050--
# 1400x1050 @ 60Hz , 65.8 kHz hsync
Modeline " 1400x1050 " 129 1400 1464 1656 1960
1050 1051 1054 1100 +HSync +VSync

知道的笔记本计算机问题

o 当前还不支持电源管理。
o 当前所开放的 LCD/CRT 热键不能在大部分东芝笔记本计算机上正常工作, 但是
东芝的Satellite 3000 系列笔记本除外。
o 当前TwinView 不能在东芝Satellite 2800 系列笔记本上正常工作。
o 影象覆盖仅仅工作在你启动的 X 的第一显示设备上。例如,
如果你在内部的 LCD 上启动 X ，运行使用影象覆盖的一个影象
应用程序 ( 通过使用XV扩展,使用 "Video Overlay" 适配器作广告)
并且那么热键换到增加的第 2 台显示设备，影象将不在第二显示设
备上出现。在这样附近工作，通过 XV 扩展做广告了的"Video Blitter "你也可以使用适配器来设置影象应用程序
( 这将总是有用的 ) ，或热键换到你在其上想要使用影象覆盖的显示设备 * before* 启动 X 。

－－－－－－－－－－－－－－－－－－－－－－－
英文原文：

__________________________________________________________________________

(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 XF86Config 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 only valid modes for TV are
640x480 and 800x600, and possibly 1024x768 if the TV encoder on
your video card is a BrookTree 871 -- your XFree86 log file should
tell you what encoder you have (look for the line: "(--) NVIDIA(0):
TV Encoder detected as").

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

      "

AL-B"  : used in Belgium, Denmark, Finland, Germany, Guinea,
               Hong Kong, India, Indonesia, Italy, Malaysia, The
               Netherlands, Norway, Portugal, Singapore, Spain,
               Sweden, and Switzerland
      "

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

AL-G"  : used in Denmark, Finland, Germany, Italy, Malaysia,
               The Netherlands, Norway, Portugal, Spain, Sweden,
               and Switzerland
      "

AL-H" : used in Belgium
"

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

AL-K1" : used in Guinea
"

AL-M" : used in Brazil
"

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

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

The line in your XF86Config file should be something like:

      Option "TVStandard" "NTSC-M"

If you don't 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 doesn't always do this correctly.  The output format
can be forced with the options:

      Option "TVOutFormat" "SVIDEO"

                  or

      Option "TVOutFormat" "COMPOSITE"

__________________________________________________________________________

(app-k) APPENDIX K: CONFIGURING A LAPTOP
__________________________________________________________________________

INSTALLATION AND CONFIGURATION

Installation and configuration of the NVIDIA Accelerated Linux Driver
Set on a laptop is the same as for any desktop environment, with a few
minor exceptions, listed below.

Starting in the 1.0-2802 release, information about the internal flatpanel
for use in initializing the display is by default generated on the fly
from data stored in the video BIOS.  This can be disabled by setting
the "SoftEDIDs" kernel option to 0.  If "SoftEDIDs" is turned off, then
hardcoded data will be chosen from a table, based on the value of the
"Mobile" kernel option.

The "Mobile" kernel option can be set to any of the following values:

0xFFFFFFFF : let the kernel module auto detect the correct value
         1 : Dell laptops
         2 : non-Compal Toshiba laptops
         3 : all other laptops
         4 : Compal Toshiba laptops
         5 : Gateway laptops

Again, the "Mobile" kernel option is only needed if SoftEDIDs is
disabled; when it is used, it's usually safest to let the kernel
module auto detect the correct value (this is the default behavior).

Should you need to alter either of these options, this can be done by
doing any of the following:

   o editing os-registry.c in the NVIDIA_kernel package

   o setting the value on the modprobe command line (eg: `modprobe
      NVdriver NVreg_SoftEDIDs=0 NVreg_Mobile=3`)

   o adding an "options" line to your module configuration file,
      usually /etc/modules.conf (eg: "options NVdriver
      NVreg_Mobile=5")

ADDITIONAL FUNCTIONALITY

TWINVIEW

All mobile NVIDIA chips support TwinView. TwinView on a laptop can
be configured in the same way as on a desktop machine (please refer
to APPENDIX I above); note that in a TwinView configuration using
the laptop's internal flat panel and an external CRT, the CRT is the
primary display device (specify it's HorizSync and VertRefresh in
the Monitor section of your XF86Config file) and the flat panel is
the secondary display device (specify it's HorizSync and VertRefresh
through the SecondMonitorHorizSync and SecondMonitorVertRefresh options).
You can also employ the UseEdidFreqs option to acquire the HorizSync and
VertRefresh from the EDID of each display devices, and not worry about
setting them in your XF86Config file (this should only be done if you
trust your display device's reported EDIDs -- please see the description
of the UseEdidFreqs option in APPENDIX D for details).

HOTKEY SWITCHING OF DISPLAY DEVICES

Besides TwinView, mobile NVIDIA chips also have the capacity to react to
an LCD/CRT hotkey event, toggling between each of the connected display
devices and each possible combination of the connected display devices
(note that only 2 display devices may be active at a time).  TwinView as
configured in your XF86Config file and hotkey functionality are mutually
exclusive -- if you enable TwinView in your XF86Config file, then the
NVIDIA X driver will ignore LCD/CRT hotkey events.

Another important aspect of hotkey functionality is that you can
dynamically connect and remove display devices to/from your laptop and
hotkey to them without restarting X.

A concern with all of this is how to validate and determine what modes
should be programmed on each display device.  First, it is immensely
helpful to use the UseEdidFreqs so that the hsync and vrefresh for
each display device can be retrieved from the display devices' EDID --
otherwise, the semantics of what the contents of the monitor section
mean constantly changes with each hotkey event.

When X is started, or when a change is detected in the list of connected
display devices, a new hotkey sequence list is constructed -- this lists
what display devices will be used with each hotkey event.  When a hotkey
event occurs, then the next hotkey state in the sequence is chosen.
Each mode requested in the XF86Config file is validated against each
display device's constraints, and the resulting modes are made available
for that display device.  If multiple display devices are to be active
at once, then the modes from each display device are paired together;
if an exact match (same resolution) can't be found, then the closest fit
is found, and the display device with the smaller resolution is panned
within the resolution of the other display device.

When vt-switching away from X, the vga console will always be restored on
the display device on which it was present when X was started.  Similarly,
when vt-switching back into X, the same display device configuration
will be used as when you vt-switched away from X, regardless of what
LCD/CRT hotkey activity occurred while vt-switched away.

NON-STANDARD MODES ON LCD DISPLAYS

Some users have had difficulty programming a 1400x1050 mode (the native
resolution of some laptop LCDs).  In version 4.0.3, XFree86 added several
1400x1050 modes to its database of default modes, but if you're using
an older version of XFree86, here is a modeline that you can use:

# -- 1400x1050 --
# 1400x1050 @ 60Hz, 65.8 kHz hsync
Modeline "1400x1050"  129  1400 1464 1656 1960
                        1050 1051 1054 1100 +HSync +VSync

KNOWN LAPTOP ISSUES

  o Power Management is not currently supported.
  o LCD/CRT hotkey switching is not currently functioning on any
Toshiba laptop, with the exception of the Toshiba Satellite
3000 series.
  o TwinView on Satellite 2800 series Toshbia laptops is not currently
functioning.
  o The video overlay only works on the first display device on which
you started X.  For example, if you start X on the internal LCD,
run a video application that uses the video overlay (uses the
"Video Overlay" adaptor advertised through the XV extension), and
then hotkey switch to add a second display device, the video will
not appear on the second display device.  To work around this,
you can either configure the video application to use the "Video
Blitter" adaptor advertised through the XV extension (this is always
available), or hotkey switch to the display device on which you want
to use the video overlay *before* starting X.

北南南北 · 发表于 2002-8-15 01:22:22

编号015
本文档已由coolflyr_reg兄弟领译，多谢coolflyr_reg兄弟。
弟兄们向您致意！
============================================
============================================

__________________________________________________________________________

(app-l) APPENDIX L: PROGRAMMING MODES
__________________________________________________________________________

The NVIDIA Accelerated Linux Driver Set supports all standard VGA and VESA
modes, as well as most user-written custom mode lines; double-scan modes
are supported on all hardware, and interlaced modes are supported on:
GeForce 256, GeForce DDR, Quadro, GeForce2 GTS/GeForce2 Pro, GeForce2 Ti,
GeForce2 Ultra, Quadro2 Pro, and all TNT products.

In general, your display device (monitor/flat panel/television) will be
a greater constraint on what modes you can use than either your NVIDIA
GPU-based video board or the NVIDIA Accelerated Linux Driver Set.

To request one or more standard modes for use in X, you can simply add a
"Modes" line such as:

      Modes "1600x1200" "1024x768" "640x480"

in the appropriate Display subsection of your XF86Config file (please see
the XF86Config(4/5) man page for details).  The following documentation
is primarily of interest if you compose your own custom mode lines,
experiment with xvidtune(1), or are just interested in learning more.
Please note that this is neither an explanation nor a guide to the fine
art of crafting custom mode lines for XFree86.  We leave that, rather,
to documents such as the XFree86 Video Timings HOWTO (which can be found
at www.linuxdoc.org).

DEPTH, BITS PER PIXEL, AND PITCH

While not directly a concern when programming modes, the bits used per
pixel is an issue when considering the maximum programmable resolution;
for this reason, it is worthwhile to address the confusion surrounding
the terms "depth" and "bits per pixel".  Depth is how many bits of
data are stored per pixel.  Supported depths are 8, 15, 16, and 24.
Most video hardware, however, stores pixel data in sizes of 8, 16, or
32 bits; this is the amount of memory allocated per pixel.  When you
specify your depth, X selects the bits per pixel (bpp) size in which to
store the data.  Below is a table of what bpp is used for each possible
depth:

      depth bpp
      ===== =====
      8    8
      15    16
      16    16
      24    32

Lastly, the "pitch" is how many bytes in the linear frame buffer there are
between one pixel's data, and the data of the pixel immediately below.
You can think of this as the horizontal resolution multiplied by the
bytes per pixel (bits per pixel divided by 8).  In practice, the pitch may
be more than this product because video hardware often has requirements
that the pitch be a multiple of some value.

MAXIMUM RESOLUTIONS

The NVIDIA Accelerated Linux Driver Set and NVIDIA GPU-based video boards
support resolutions up to 2048x1536, though the maximum resolution
your system can support is also limited by the amount of video memory
(see USEFUL FORMULAS for details) and the maximum supported resolution
of your display device (monitor/flat panel/television).  Also note that
while use of a video overlay does not limit the maximum resolution or
refresh rate, video memory bandwidth used by a programmed mode does
effect the overlay quality.

USEFUL FORMULAS

The maximum resolution is a function both of the amount of video memory
and the bits per pixel you elect to use:

      HR * VR * (bpp/8) = Video Memory Used

In other words, the amount of video memory used is equal to the horizontal
resolution (HR) multiplied by the vertical resolution (VR) multiplied by
the bytes per pixel (bits per pixel divided by eight).  Technically, the
video memory used is actually the pitch times the vertical resolution,
and the pitch may be slightly greater than (HR * (bpp/8)) to accommodate
hardware requirements that the pitch be a multiple of some value.

Please note that this is just memory usage for the frame buffer; video
memory is also used by other things such as OpenGL or pixmap caching.

Another important relationship is that between the resolution, the pixel
clock (aka dot clock) and the vertical refresh rate:

      RR = PCLK / (HFL * VFL)

In other words, the refresh rate (RR) is equal to the pixel clock (PCLK)
divided by the total number of pixels: the horizontal frame length (HFL)
multiplied by the vertical frame length (VFL) (note that these are the
frame lengths, and not just the visible resolutions).  As described in
the XFree86 Video Timings HOWTO, the above formula can be rewritten as:

      PCLK = RR * HFL * VFL

Given a maximum pixel clock, you can adjust the RR, HFL and VFL as
desired, as long as the product of the three is consistent.  The pixel
clock is reported in the log file when you run X with verbose logging:
`startx -- -logverbose 5`.  Your XFree86.0.log should contain several
lines like:

(--) NVIDIA(0): Display Device 0: maximum pixel clock at  8 bpp: 350 MHz
(--) NVIDIA(0): Display Device 0: maximum pixel clock at 16 bpp: 350 MHz
(--) NVIDIA(0): Display Device 0: maximum pixel clock at 32 bpp: 300 MHz

which indicate the maximum pixel clock at each bit per pixel size.

HOW MODES ARE VALIDATED

During the PreInit phase of the X server, the NVIDIA X driver validates
all requested modes by doing the following:

  o Take the intersection of the HorizSync and VertRefresh ranges given
by the user in the XF86Config with the ranges reported by the monitor
in the EDID (Extended Display Identification Data); this behavior
can be disabled by using the "IgnoreEDID" option in which case the
X driver will blindly accept the HorizSync and VertRefresh ranges
given by the user.

  o Call the xf86ValidateModes() helper function, which finds modes with
the names the user specified in the XF86Config file, pruning
out modes with invalid horizontal sync frequencies or vertical
refresh rates, pixel clocks larger than the maximum pixel clock
for the video card, or resolutions larger than the virtual
screen size (if a virtual screen size was specified in the
XF86Config file).  Several other constraints are applied; see
xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes().

  o All modes returned from xf86ValidateModes() are then examined to make
sure their resolutions are not larger than the largest mode reported
by the monitor's EDID (this can be disabled with the "IgnoreEDID"
option.  If the display is a TV, each mode is checked to make sure
it has a resolution that is supported by the TV encoder (usually
only 800x600 and 640x480 are supported by the encoder).

  o All remaining modes are then checked to make sure they pass the
constraints described below in ADDITIONAL MODE CONSTRAINTS.

The last two steps are also done when each mode is programmed, to
catch potentially invalid modes submitted by the XF86VidModeExtension
(eg xvidtune(1)).  For TwinView, the above validation is done for the
modes requested for each display device.

ADDITIONAL MODE CONSTRAINTS

Below is a list of additional constraints on a mode's parameters that
must be met.

  o The horizontal resolution (HR) must be a multiple of 4 and be less
than or equal to 2048.
  o The horizontal blanking width (the maximum of the horizontal frame
length and the horizontal sync end minus the minimum of the horizontal
resolution and the horizontal sync start (max(HFL,HSE) - min(HR,HSS))
must be a multiple of 4 and be less than or equal to 1024.
  o The horizontal sync start (HSS) must be a multiple of 4 and be less
than or equal to 4088.
  o The horizontal sync width (the horizontal sync end minus the
horizontal sync start (HSE - HSS)) must be a multiple of 4 and be
less than or equal to 256.
  o The horizontal frame length (HFL) must be a multiple of 4 and be
less than or equal to 4128 and be greater than or equal to 40.
  o The vertical resolution (VR) must be less than or equal to 2048.
  o The vertical blanking width (the maximum of the vertical frame length
and the vertical sync end minus the minimum of the vertical resolution
and the vertical sync start (max(VFL,VSE) - min(VR,VSS)) must be
less than or equal to 128.
  o The vertical sync start (VSS) must be less than or equal to 2047.
  o The vertical sync width (the vertical sync end minus the vertical sync
start (VSE - VSS)) must be less than or equal to 16.
  o The vertical frame length (VFL) must be less than or equal to 2049
and be greater than or equal to 2.

Here is an example mode line demonstrating the use of each abbreviation
used above:

# Custom Mode line for the SGI 1600SW Flatpanel
#       name          PCLK  HR HSS  HSE  HFL  VR VSS  VSE  VFL

Modeline "sgi1600x1024" 106.9 1600 1632 1656 1672 1024 1027 1030 1067

SEE ALSO:

An XFree86 modeline generator, conforming to the GTF Standard has
been posted to the XFree86 Xpert mailing list:

      http://www.xfree86.org/pipermail/xpert/2001-October/012070.html

For additional modeline generators, try searching for "modeline"
on freshmeat.net.

北南南北 · 发表于 2002-8-15 01:22:46

编号016
本文档已由dragonnapalm兄弟领译，多谢dragonnapalm兄弟。
弟兄们向您致意！
============================================
============================================

编号016

———————————————————————————————————
（app-m）附录 M：画面交换模式、窗口交换模式、以及UBB（统一反向缓冲器）
———————————————————————————————————
从发行版1.0-2313开始，NVIDIA Linux加速驱动包开始支持统一反向缓冲器（UBB

）、画面交换模式以及窗口交换模式。这些特性在某些场合可以提供更高的性能

提升。下面是对它们分别的描述：

·画面交换模式：所有的GeForce系列显示卡或者更新的硬件设备已经包含此种特

性（注：不包括TNT/TNT2系列产品），它可以在进行同步垂直刷新的时候激活，

使OpenGL应用程序在单一全屏幕显示的时候更加清晰。缓冲交换将通过改变DAC所

扫描出的缓存来完成，而不是通过将后置缓存的内容复制到前置缓存来实现；此

种机制可以普遍地使性能得到进一步的提升，并且在场景折回的过程中可以实现

无损交换（当__GL_SYNC_TO_VBLANK 已被设置）。该特性可以在XF86Config中使

用“PageFlip”选项来禁用

·统一反向缓冲器（UBB）：UBB在所有的Quadro系列芯片中已经得到支持（Quadr

o4 200/400NVS 除外），并且当显存足够时，它已经被默认设置为打开。它可以

使用在附录D中所描述的 XF86Config “UBB”选项来禁用。当UBB被打开时，所有

的窗口将使用统一的背景、模板及深度缓冲。在出现很多窗口的情况下，背景、

模板和深度所占用的显存将不会超过全屏幕状态下所使用的大小。但是，即使是

对单一的小型窗口，背景、模板及深度的对显存的占用将和全屏幕窗口所占用的

大小相同，这样的话，显存的使用效率可能要低于采用非UBB显示的模式。

·窗口交换模式：该特性需要UBB的支持，并且只在Quadro芯片上可用。当单一的

OpenGL窗口出现时，该窗口的缓存可以通过DAC扫描出的缓存来改变，而不是将后

置缓存的内容移动到前置缓存中去。这和画面交换模式类似，但是它取消了该窗

口必须为清晰显示状态以及为全屏模式的限制。该特性只能工作在单一的OpenGL

窗口模式下，并且默认情况下为禁用。要启用，请使用附录D中所描述的XF86Conf

ig “WindowFlip”选项

______________________________________________________________________
(app-n) 附录N: 已知的问题
______________________________________________________________________

以下的问题在此发行版中仍然存在，并且有待于解决：

·OpenGL + Xinerama：在Xinerama环境下，除了在单头显示模式下，OpenGL将不

会被起用

·OpenGL及dlopen()函数
在使用了dlopen()函数的程序中，存在着一系列问题有待商讨。这些问题存在于

较老版本的glibc动态装载程序（如：随RedHat7.2所附带的版本）以及像雷神之

锤3、辐射这样的应用程序。欲了解详细信息，请参阅常见问题解答章节

·DPMS及双头显示
当使用双头显示的时候，DPMS中的“延缓”及“等待”模式在第二台CRT显示器上

不会正确工作。该显示器的屏幕会变为空白，而不是调整为被要求的DPMS状态。

·DPMS及平板显示器
DPMS中的“延缓”及“等待”模式在平板显示器上不会正确工作。显示器的屏幕

将变为空白，而不是调整为被要求的DPMS状态

·多显示卡以及多显示器
在某些情况下，从显示卡不会被NVdriver内核模块正确初始化，要解决该问题，

可以激活XFree86

Int10模块来软起动所有的从显示卡。请参阅“附录D：XF86CONFIG配置”章节获

取详细信息。

·膝上型电脑
如果你使用的是膝上型电脑，请在附录D中参阅“已知的膝上型电脑问题”部分

·FSAA（全屏幕抗锯齿）
当FSAA被激活时（__GL_FSAA_MODE变量环境已经被赋上激活FSAA的值，同时多次

取样视觉效果已经被选择）。当调整窗口大小的时候，该渲染可能会被破坏

硬件问题

该部分描述了不会被修复的问题。通常这些问题已经超出了NVIDIA的控制范围。

下面是这些问题的列表：

·技嘉GA-6BX主板
该主板所使用的LinFinity校整器安装在了额定电流被调整为5A的3.3V电压轨上—

—这少于AGP规格所要求的6A。当诊断或应用程序运行时，校整器温度升高，将会

引起NVIDIA芯片的电压降低到2.2V。在此情况下，校整器将不能在3.3V电压轨上

供给NVIDIA芯片所需要的足够电流。

如果显示卡有一个可变式校整器，或者外部电源供应连接在了3.3V电压轨上，该

问题则不会发生。

·带AGP2X的VIA KX133及694X芯片组
在使用VIA KX133或694X 芯片组的Athlon主板上，例如华硕K7V主板，NVIDIA驱动

将会在某一种信号的影响下被默认设置为AGP2X模式，以不足的驱动强度来工作。

·带AGP1X的Irongate芯片组
在使用Irongate芯片组的Athlon主板上，AGP1X传输模式将会在该芯片组中出现信

号完整性的问题

·ALi 芯片组，ALi1541及ALi1647
在ALi1541及ALi1647芯片组中，由于时间性问题及信号完整性问题，NVIDIA驱动

将禁用AGP工作模式。请参阅“附录G：ALI特别问题”获得ALi芯片组的更多信息。

－－－－－－－－－－－－－－－－－－－－－－－
英文原文：

__________________________________________________________________________

(app-m) APPENDIX M: PAGE FLIPPING, WINDOW FLIPPING, AND UBB
__________________________________________________________________________

Starting with the 1.0-2313 driver release, the NVIDIA Accelerated
Linux Driver Set supports Unified Back Buffer (UBB), Page Flipping,
and Window Flipping.  These features can provide performance gains in
certain situtations.  Here is a discription of each:

  o Page Flipping: This feature is available on all GeForce or newer
      hardware (ie: not TNT/TNT2 products), and is enabled in the
      case of a single full screen unobscured OpenGL application when
      syncing to vblank.  Buffer swapping is done by changing which
      buffer the DAC scans out rather than copying the back buffer
      contents to the front buffer; this is generally a much higher
      performance mechanism and allows tearless swapping during the
      retrace (when __GL_SYNC_TO_VBLANK is set).  This feature can be
      disabled with the PageFlip XF86Config option.

  o Unified Back Buffer (UBB): UBB is available only on the Quadro family
      of GPUs (Quadro4 200/400NVS excluded) and is enabled by default
      when there is sufficient video memory available.  This can be
      disabled with the UBB XF86Config option described in Appendix D.
      When UBB is enabled, all windows share the same back, stencil
      and depth buffer.  When there are many windows, the back, stencil
      and depth usage will never exceed the size of that used by a
      full screen window.  However, even for a single small window
      the back, stencil and depth usage are that of a full screen
      window so in that case video ram may be used less efficiently
      than in the non-UBB case.

  o Window Flipping: This feature requires UBB, and thus is only available
      on Quadro parts.  When there is a single OpenGL window this
      window's buffers can be swapped by changing which buffer the DAC
      scans out rather than blitting the back buffer contents to the
      front buffer.  This is similar to Page Flipping but removes the
      restriction that the window be unobscured and be full screen.
      This only works when there is a single OpenGL window.  Window
      Flipping is disabled by default and can be enabled with the
      "WindowFlip" XF86Config option described in Appendix D.

__________________________________________________________________________

(app-n) APPENDIX N: KNOWN ISSUES
__________________________________________________________________________

The following problems still exist in this release and are in the process
of being resolved.

  o OpenGL + Xinerama
      Currently, OpenGL will not display to anything other than the
      first head in a Xinerama environment.

  o OpenGL and dlopen()
      There are some issues with older versions of the glibc dynamic
      loader (e.g., the version that shipped with RedHat 7.2) and
      applications such as Quake3 and Radiant, that use dlopen().
      See the FREQUENTLY ASKED QUESTIONS section for more details.

  o DPMS and TwinView
      DPMS Modes "suspend" and "standby" do not work correctly on
      a second CRT when using TwinView.  The screen becomes blank
      instead of the monitor being set to the requested DPMS state.

  o DPMS and Flat Panel
      DPMS modes "suspend" and "standby" do not work correctly on a
      flat panel display.  The screen becomes blank instead of the
      flat panel being set to the requested DPMS state.

  o Multicard, Multimonitor
      In some cases, the secondary card is not initialized correctly
      by the NVdriver kernel module. You can work around this by enabling
      the XFree86 Int10 module to soft-boot all secondary cards. See
      "APPENDIX D: XF86CONFIG OPTIONS" for details.

  o Laptop
      If you are using a laptop please see the "Known Laptop Issues" in
      APPENDIX D.

  o FSAA
      When FSAA is enabled (the __GL_FSAA_MODE environment variable
      is set to a value that enables FSAA and a multisample visual is
      chosen), the rendering may be corrupted when resizing the window.

HARDWARE ISSUES

This section describes problems that will not be fixed.  Usually, the
source of the problem is beyond the control of NVIDIA.  Following is
the list of problems:

  o Gigabyte GA-6BX Motherboard
      This motherboard uses a LinFinity regulator on the 3.3-V rail
      that is rated to only 5 A -- less than the AGP specification,
      which requires 6 A.  When diagnostics or applications are
      running, the temperature of the regulator rises, causing the
      voltage to the NVIDIA chip to drop as low as 2.2 V.  Under these
      circumstances, the regulator cannot supply the current on the
      3.3-V rail that the NVIDIA chip requires.

      This problem does not occur when the graphics board has a
      switching regulator or when an external power supply is connected
      to the 3.3-V rail.

  o VIA KX133 and 694X Chip sets with AGP 2x
      On Athlon motherboards with the VIA KX133 or 694X chip set, such
      as the ASUS K7V motherboard, NVIDIA drivers default to AGP 2x mode
      to work around insufficient drive strength on one of the signals.

  o Irongate Chip sets with AGP 1x
      AGP 1x transfers are used on Athlon motherboards with the Irongate
      chip set to work around a problem with the signal integrity of
      the chip set.

  o ALi chipsets, ALi1541 and ALi1647
      On ALi1541 and ALi1647 chipsets, NVIDIA drivers disable AGP to work
      around timing issues and signal integrity issues. See "APPENDIX G:
      ALI SPECIFIC ISSUES" for more information on ALi chipsets.

北南南北 · 发表于 2002-8-15 01:23:07

编号017
本文档已由flynng兄弟领译，多谢flynng兄弟。
弟兄们向您致意！
============================================
============================================

编号017

__________________________________________________________________________

(app-o)附录O: PROC接口
__________________________________________________________________________
proc 文件系统接口能使你得知驱动的运行时间,NVIDIA显卡和AGP的状态

这些信息保存在/proc/driver/nvidia的几个文件中.下面是对这些文件的简单介绍：

o version
列出已安装驱动的升级修正和建立在linux核心组件上的GUN C编辑器的版本

o cards/0...3
提供每一个已安装的NVIDIA图形适配器的信息 (型号名称, IRQ中断, BIOS 版本, 总线类型). 请注意,BIOS版本信息只有在X系统运行的时候才能发挥作用。

o agp/card
关于AGP接口的AGP性能方面的信息.

o agp/host-bridge
关于桥接方面的信息 (版本和AGP的性能).

o agp/status
当前的AGP状态. 当你的系统打开了AGP性能支持后,AGP驱动才能运行。这将显示出AGP的速率和状态信息的快速写入，以及Side BAND寻址。

这种AGP驱动是NVIDIA驱动（NVIDIA内置AGP驱动）或AGGART驱动（linux核心的agpgart.o驱动）的其中一个. 如果你看到"inactive"在AGPGART前面, 这表示这个 AGP 芯片组是AGPGART驱动的,但是当前并没有运作.

SBA和快速写入显示出是否每一个功能当前都在运作. 有几个因素决定这些功能是否在运作. 最主要的，AGP接口和桥接必须支持这些功能. 即使支持, 考虑到系统稳定性，驱动也不一定会打开这些功能. 最明显的就是AGP的快速写入。

__________________________________________________________________________

(app-p)附录P: XVMC支持
__________________________________________________________________________

X-Video Motion Compensation(XvMC)版本1.0 API（应用编程接口）的支持只有GeForce4并且只有only GeForce4系列产品.
现在适合dlopening的有静态连接库"libXvMCNVIDIA.a"和动态连接库
"libXvMCNVIDIA_dynamic.so"。
GeForce4 MX产品支持XvMC's "IDCT"和"motion-compensation"（动态补偿）
的加速性能. GeForce4 Ti 系列产品只支持motion-compensation（动态补偿）.
AI44 and IA44 subpictures
are supported. 4:2:0 Surfaces up to 2032x2032 are supported.

libXvMCNVIDIA监视环境变量XVMC_DEBUG,同时将一些调试信息(debug)输出到stderr（标准错误流），前提是设置了
相应的整数值。
'0' 禁止输出调试信息。
'1' 在失败的情况下输出调试信息。
'2' 或者进一步输出警告消息。

__________________________________________________________________________

(app-q)附录Q: GLX支持
__________________________________________________________________________

GLX 1.2版本的性能支持有以下的扩展
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_SGIX_fbconfig
GLX_SGIX_pbuffer
GLX_ARB_get_proc_address

对于以上扩展性能的描述, 请在下面站点察看OpenGL extension registry
http://oss.sgi.com/projects/ogl-sam...stry/index.html

GLX 1.3还没有被支持.

－－－－－－－－－－－－－－－－－－－－－－－
英文原文：

__________________________________________________________________________

(app-o) APPENDIX O: PROC INTERFACE
__________________________________________________________________________

The /proc filesystem interface allows you to obtain run-time information
about the driver, any installed NVIDIA graphics cards and the AGP status.

This information is held by several files in /proc/driver/nvidia. This is
a brief description for each one of these files:

  o version
      Lists the installed driver revision and the version of the GNU C
      compiler used to build the Linux kernel module.

  o cards/0...3
      Provides information about each of the installed NVIDIA graphics
      adapters (model name, IRQ, BIOS version, Bus Type). Please note
      that the BIOS version is only available while X is running.

  o agp/card
      Information about the installed AGP card's AGP capabilities.

  o agp/host-bridge
      Information about the host bridge (model and AGP capabilities).

  o agp/status
      The current AGP status. If AGP support has been enabled on your
      system, the AGP driver being used, the AGP rate and information
      about the status of AGP Fast Writes and Side Band Addressing is
      shown.

      The AGP driver is either one of NVIDIA (NVIDIA's built-in AGP
      driver) or AGPGART (the Linux kernel's agpgart.o driver). If
      you see "inactive" next to AGPGART, then this means that the
      AGP chipset was programmed by AGPGART, but is not currently in
      use.

      SBA and Fast Writes indicate whether either one of the features
      is currently in use. Please note that several factors decide if
      support for either will be enabled. First of all, both the AGP
      card and the host bridge must support the feature. Even if both
      do support it, the driver may decide not to use it in favor of
      system stability. This is particularly true of AGP Fast Writes.

__________________________________________________________________________

(app-p) APPENDIX P: XVMC SUPPORT
__________________________________________________________________________

This release includes support for the X-Video Motion Compensation
(XvMC) version 1.0 API on GeForce4 and only GeForce4 products.
There is a static library "libXvMCNVIDIA.a" and a dynamic one
"libXvMCNVIDIA_dynamic.so" which is suitable for dlopening.
GeForce4 MX products support both XvMC's "IDCT" and "motion-compensation"
levels of acceleration.  GeForce4 Ti products only support
the motion-compensation level.  AI44 and IA44 subpictures
are supported.  4:2:0 Surfaces up to 2032x2032 are supported.

libXvMCNVIDIA observes the XVMC_DEBUG environment variable and will
provide some debug output to stderr when set to an appropriate integer
value.  '0' disables debug output.  '1' enables debug output for failure
conditions.  '2' or higher enables output of warning messages.

__________________________________________________________________________

(app-q) APPENDIX Q: GLX SUPPORT
__________________________________________________________________________

This release supports GLX 1.2 with the following extensions
GLX_EXT_visual_info
GLX_EXT_visual_rating
GLX_SGIX_fbconfig
GLX_SGIX_pbuffer
GLX_ARB_get_proc_address

For a description of these extensions, please see the OpenGL extension
registry at http://oss.sgi.com/projects/ogl-sample/registry/index.html

GLX 1.3 is not yet supported.

		自动登录	找回密码
密码			注册