LinuxSir.cn,穿越时空的Linuxsir!

 找回密码
 注册
搜索
热搜: shell linux mysql
查看: 2156|回复: 5

轻松校对NVIDIA说明文件,编号013!!![11月6日更新]

[复制链接]
发表于 2002-11-5 23:44:32 | 显示全部楼层 |阅读模式
翻译原文:
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=4642

已经校对过的
编号001-012:
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=5738
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=6466
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=6526
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=6842
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=6973
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=7451
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=8154
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=8214
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=8615
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=9380
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=10873
http://www.linuxsir.cn/forum.php?mod=viewthread&tid=11740
有新意见的朋友还可以继续跟贴,谢谢





今天开始校对编号013,希望大家热情参与:

******************************

编号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-11-9 21:49:47 | 显示全部楼层
*********************************************************************
由于最近实在是太忙,所以暂时没有办法给出全文的翻译了,只好先贴出翻译过了的一小部分,剩下的内容我会在处理完手头的事情之后尽快给出,如果有兄弟能翻译完余下的部分,那是再好不过了,可以提高整个校对计划的进度。如果这篇翻译实在闲置太长的话,请版主先贴出后面的校对,谢谢!!
**********************************************************************

013的部分全文翻译:

_____________________________________________________________________

(app-g) 附录 G: ALI芯片组特殊问题
______________________________________________________________________

以下的提示可以帮助你稳定一些有问题的ALI芯片组系统:
·在BIOS中禁用 TURBO AGP MODE 选项
·如果你正在使用P5A系列主板,将BIOS升级到修正版本1002 BETA 2
·如果你的BIOS版本为1007、1007A或1009,则需要在BIOS将IO Recovery Time选项调整到4 cycles
·为了能使一些具有严重系统稳定性的问题的芯片组正常工作,在一些使用ALi芯片组的主板上AGP功能将被禁用(如Ali1541,ALi1647),要强制启用AGP,请在os-registry.c中参看有关 NVreg_EnableALiAGP 的注解

______________________________________________________________________

(app-h) 附录 H: TNT芯片特殊问题
______________________________________________________________________

一些有关SGRAM/SDRAM TNT显卡的问题需要解决:如果你的显示卡安装了错误的BIOS(虽然这种可能性很小),那么这个驱动程序将不会正常工作

如果这个驱动没有正常工作,请按以下步骤:
·当系统引导时观察你的显示器,在最初的时候,屏幕上将显示出你的显示卡所使用的显存类型。它们可能是SGRAM或SDRAM
·取得最新的NVIDIA_kernel tar压缩文件包
·从内核模块源代码中编辑"os-registry.c"文件,查找"NVreg_VideoMemoryTypeOverride"变量,将该变量赋值为你的显存类型(数值上请参看文件中该变量的上面一行)
·由于在正常情况下我们不会使用该变量,所以请将该文件中位于此变量大约10行之上中的"#if 0"改为"#if 1".
·重新编译并重新安装驱动程序(使用make命令)

______________________________________________________________________

(app-i) 附录 I: 配置TWINVIEW (双头显示)
______________________________________________________________________

TwinView只被支持双头显示功能的NVIDIA图形处理芯片所支持,如 GeForce2 MX, GeForce2 Go, Quadro2 MXR, Quadro2 Go及GeForce4 全系列芯片。请联系你的显卡制造商来确认你的显卡是否支持TwinView

在任意配置下,TwinView可以让两台显示设备(数字平面显示器、CRT显示器、电视)显示单一X屏幕中的内容。这种多监视器显示方式明显要优于其它技术(如Xinerama):
·只使用单一的X屏幕显示。NVIDIA驱动程序隐藏了X服务器中所有多显示设备的信息。所有与X有关的内容都将使用单一屏幕显示
·两个显示设备共享同一个帧缓冲(Frame Buffer)。这样TwinView可以使用单一显示中的所有功能(如OpenGL)
·模拟另一个单一桌面不需要额外的费用或设置

[暂时到此为止,对不起,如果可以的话请各位兄弟多多帮忙!!多谢!!]
 楼主| 发表于 2002-11-9 21:54:04 | 显示全部楼层
dragonnapalm兄,不要紧,慢慢来,这个不是给您一个人的任务,是希望大家共同参与的,只可惜现在几乎只剩下兄弟您一个人努力了,我一直坚持过些天才更新,多置顶几天,也就是希望能有更多的兄弟参与进来。
兄弟们,当初的热情跑哪去了?
发表于 2002-11-9 22:40:13 | 显示全部楼层
我也刚开始翻译了一个开头,没来得及接下去。
发表于 2002-11-10 00:04:33 | 显示全部楼层
本来想和兄弟们共同作战,但还是一点力也出不上,上来后就整理论坛,我计划是用半个月的时间,现在才整理完两个版。整理版务难在帖子的标题上,重复的帖子以及好多的帖子都没有发到相应的版面里。还有些没有回复的,仍得回复。
请兄弟们多多费心,慢点不要紧,我们可能也就也篇了。
在这校对之中,没有两位兄台,真不知道什么样子。辛苦了。

北南 致意
发表于 2002-11-10 13:23:10 | 显示全部楼层
013部分全文翻译:

XF86CONFIG TwinView 选项

要激活TwinView,你必须在XF86Config文件的 Screen 部分中指定以下选项:

Option "TwinView"
Option "SecondMonitorHorizSync" "<水平刷新率范围>"
Option "SecondMonitorVertRefresh" "<垂直刷新率范围>"
Option "MetaModes" "<metamodes列表>"

你也可以使用以下的选项,尽管你可能不需要:

选项 "TwinViewOrientation" "<头输出(head)1到头输出(head)2的联系>"
选项 "ConnectedMonitor" "<已连接的显示设备列表>"

请参看以下对每个选项的详细描述:

·TwinView
要激活TwinView必须使用该选项,如果没有该选项,其他所有与TwinView有关的选项将被忽略

·SecondMonitorHorizSync, SecondMonitorVertRefresh
你需要使用这些选项来约束限制第二台显示器。对于他们的赋值则需要与 Monitor 部分中的"HorizSync"及"VertRefresh"条目中的赋值相一致。XF86Config的说明文档作出了以下的解释:这些范围可能是一个用逗号来分开不同值或范围值的列表,范围值是由用破折号分开的不同值而组成的。HorizSync的单位为kHz,VertRefresh的单位为Hz。如果你相信你的显示设备的EDID(扩展显示标识数据),你可以使用"UseEdidFreqs"来代替这些选项。(请参看附录 D 获得"UseEdidFreqs" 选项的描述)

·MetaModes
单一的MetaMode选项描述了在特定时间每一显示设备所应该使用的显示模式。多个MetaModes 选项则可以列出这些模式的组合以及使用它们的顺序。当NVIDIA驱动程序告诉X服务器哪些模式可用时,这是MetaMode与X进行通讯的最小限制范围,但"per display
device"模式则包含在了NVIDIA驱动程序之内。在MetaMode的句法中,MetaMode中的所有模式将被逗号分开,而多个MetaMode则被分号分开。如:

"<mode name 0>, <mode name 1>; <mode name 2>, <mode name 3>"

<mode name 0>是在显示设备0上所使用的显示模式名称,同时在显示设备1上所使用的模式为<mode name 1>。显示模式间的转换将导致在显示设备0上使用<mode name 2>,在显示设备1上使用<mode name 3>。这里是一个XF86Config示例文件中的MetaMode条目:

Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768"

如果你想让你的显示设备不激活某一个MetaModes,你可以使用一个名为"NULL"的模式,或简单的忽略所有的模式名称:

"1600x1200, NULL; NULL, 1024x768"

"1600x1200; , 1024x768"
您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 返回顶部 返回列表