1 NVIDIA Accelerated FreeBSD Graphics Driver README and Installation Guide
4 Last Updated: 2007/11/16
5 Most Recent Driver Version: 169.07
9 2701 San Tomas Expressway
16 ALL NVIDIA DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS,
17 DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, "MATERIALS")
18 ARE BEING PROVIDED "AS IS." NVIDIA MAKES NO WARRANTIES, EXPRESSED, IMPLIED,
19 STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND EXPRESSLY DISCLAIMS
20 ALL IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A
21 PARTICULAR PURPOSE. Information furnished is believed to be accurate and
22 reliable. However, NVIDIA Corporation assumes no responsibility for the
23 consequences of use of such information or for any infringement of patents or
24 other rights of third parties that may result from its use. No license is
25 granted by implication or otherwise under any patent or patent rights of
26 NVIDIA Corporation. Specifications mentioned in this publication are subject
27 to change without notice. This publication supersedes and replaces all
28 information previously supplied. NVIDIA Corporation products are not
29 authorized for use as critical components in life support devices or systems
30 without express written approval of NVIDIA Corporation.
32 NVIDIA, the NVIDIA logo, NVIDIA nForce, GeForce, NVIDIA Quadro, Vanta, TNT2,
33 TNT, RIVA, RIVA TNT, Quincunx Antialiasing, and TwinView are registered
34 trademarks or trademarks of NVIDIA Corporation in the United States and/or
37 FreeBSD is a registered trademark of the FreeBSD Foundation. Linux is a
38 registered trademark of Linus Torvalds. Intel and Pentium are registered
39 trademarks of Intel Corporation. Athlon is a registered trademark of Advanced
40 Micro Devices. OpenGL is a registered trademark of Silicon Graphics Inc. PCI
41 Express is a registered trademarks and/or service marks of PCI-SIG. Windows is
42 a registered trademark of Microsoft Corporation in the United States and other
43 countries. Other company and product names may be trademarks or registered
44 trademarks of the respective owners with which they are associated.
47 Copyright 2006 NVIDIA Corporation. All rights reserved.
49 ______________________________________________________________________________
52 ______________________________________________________________________________
54 Chapter 1. Introduction
55 Chapter 2. Installing the NVIDIA Driver
56 Chapter 3. Using Linux Compatibility Support
57 Chapter 4. Configuring X for the NVIDIA Driver
58 Chapter 5. Frequently Asked Questions
59 Chapter 6. Common Problems
60 Chapter 7. Known Issues
61 Chapter 8. Specifying OpenGL Environment Variable Settings
62 Chapter 9. Configuring AGP
63 Chapter 10. Configuring TwinView
64 Chapter 11. Configuring GLX in Xinerama
65 Chapter 12. Configuring Multiple X Screens on One Card
66 Chapter 13. Configuring TV-Out
67 Chapter 14. Using the XRandR Extension
68 Chapter 15. Configuring a Notebook
69 Chapter 16. Programming Modes
70 Chapter 17. Configuring Flipping and UBB
71 Chapter 18. Using the X Composite Extension
72 Chapter 19. Using the nvidia-settings Utility
73 Chapter 20. Configuring SLI and Multi-GPU FrameRendering
74 Chapter 21. Configuring Frame Lock and Genlock
75 Chapter 22. Configuring Depth 30 Displays
76 Chapter 23. NVIDIA Contact Info and Additional Resources
78 Chapter 25. Acknowledgements
80 Appendix A. Minimum Software Requirements
81 Appendix B. Installed Components
82 Appendix C. The Sysctl Interface
83 Appendix D. Configuring Low-level Parameters
84 Appendix A. Supported NVIDIA GPU Products
85 Appendix B. X Config Options
86 Appendix C. Display Device Names
87 Appendix D. GLX Support
88 Appendix E. Dots Per Inch
89 Appendix F. XvMC Support
91 ______________________________________________________________________________
93 Chapter 1. Introduction
94 ______________________________________________________________________________
97 1A. ABOUT THE NVIDIA ACCELERATED FREEBSD GRAPHICS DRIVER
99 The NVIDIA Accelerated FreeBSD Graphics Driver brings accelerated 2D
100 functionality and high-performance OpenGL support to FreeBSD x86 with the use
101 of NVIDIA graphics processing units (GPUs).
103 These drivers provide optimized hardware acceleration for OpenGL and X
104 applications and support nearly all recent NVIDIA GPU products (see Appendix E
105 for a complete list of supported GPUs). TwinView, TV-Out and flat panel
106 displays are also supported.
109 1B. ABOUT THIS DOCUMENT
111 This document provides instructions for the installation and use of the NVIDIA
112 Accelerated FreeBSD Graphics Driver. Chapter 2, Chapter 3 and Chapter 4 walk
113 the user through the process of downloading, installing and configuring the
114 driver. Chapter 5 addresses frequently asked questions about the installation
115 process, and Chapter 6 provides solutions to common problems. The remaining
116 chapters include details on different features of the NVIDIA FreeBSD Driver.
117 Frequently asked questions about specific tasks are included in the relevant
121 1C. ABOUT THE AUDIENCE
123 It is assumed that the user and reader of this document has at least a basic
124 understanding of FreeBSD techniques and terminology. However, new FreeBSD
125 users can refer to for details on parts of the installation process.
128 1D. ADDITIONAL INFORMATION
130 In case additional information is required, Chapter 23 provides contact
131 information for NVIDIA FreeBSD driver resources, as well as a brief listing of
134 ______________________________________________________________________________
136 Appendix A. Minimum Software Requirements
137 ______________________________________________________________________________
139 The official minimum software requirements for the NVIDIA FreeBSD Graphics
140 Driver are as follows:
142 Software Element Min Requirement
143 ---------------------------------- ----------------------------------
144 Kernel FreeBSD 5-STABLE (5.3 or later)
145 XFree86/X.Org 4.2/6.7.0
147 Additionally, the kernel source tree must be installed in /usr/src/sys
148 (package 'ssys' installed)
150 Note that FreeBSD -STABLE versions older than FreeBSD 5.3 and FreeBSD 6.x/7.x
151 -CURRENT development snapshots are not supported.
153 ______________________________________________________________________________
155 Chapter 2. Installing the NVIDIA Driver
156 ______________________________________________________________________________
158 This installation procedure will likely be simplified further in the future,
159 but for the moment you will need to download the NVIDIA FreeBSD Graphics
160 Driver archives from the NVIDIA website, extract them to a temporary location
161 of your choice, and run the following from the root of the extracted directory
166 This will compile the NVIDIA FreeBSD kernel module, install it, and kldload
167 it. It will also remove any conflicting OpenGL libraries, and install the
168 NVIDIA OpenGL libraries. The '/dev/nvidia' device files will be created
169 (unless the system is using devfs), and your '/boot/loader.conf' file will be
170 updated to automatically load the NVIDIA kernel module on boot, as well as the
171 Linux ABI compatiability module should you not have it compiled into your
174 ______________________________________________________________________________
176 Appendix B. Installed Components
177 ______________________________________________________________________________
179 The NVIDIA Accelerated FreeBSD Graphics Driver consists of the following
182 Installed File Location
183 ---------------------------------- ----------------------------------
184 nvidia.ko /boot/modules
185 libGL.so /usr/X11R6/lib
186 libGL.so.1 /usr/X11R6/lib
187 libnvidia-tls.so /usr/X11R6/lib
188 libnvidia-tls.so.1 /usr/X11R6/lib
189 libnvidia-cfg.so /usr/X11R6/lib
190 libnvidia-cfg.so.1 /usr/X11R6/lib
191 libGLcore.so /usr/X11R6/lib
192 libGLcore.so.1 /usr/X11R6/lib
193 nvidia_drv.so /usr/X11R6/lib/modules/drivers
194 libglx.so /usr/X11R6/lib/modules/extensions
195 libglx.so.1 /usr/X11R6/lib/modules/extensions
196 nvidia-xconfig /usr/X11R6/bin
197 nvidia-xconfig.1 /usr/X11R6/man/man1
198 nvidia-settings /usr/X11R6/bin
199 nvidia-settings.1 /usr/X11R6/man/man1
205 libGL.so.169.07 /compat/linux/usr/lib
206 libnvidia-tls.so.169.07 /compat/linux/usr/lib
207 libGLcore.so.169.07 /compat/linux/usr/lib
210 ______________________________________________________________________________
212 Chapter 3. Using Linux Compatibility Support
213 ______________________________________________________________________________
215 If you wish to run Linux OpenGL applications on your FreeBSD computer, you
216 will need to make sure that several prerequisites are met.
218 First, you should follow the basic Linux compatibility installation guide in
219 the FreeBSD Handbook (install the linux_base package, etc). Once the basic
220 components are in place, you will need to install the NVIDIA Linux OpenGL
221 libraries in '/compat/linux/usr/lib' (do not brandelf them!); if the
222 '/compat/linux/usr/lib/' directory exists when you install the FreeBSD driver,
223 the Linux compatibility OpenGL libraries will automatically be installed.
225 Additionally, the 'nvidia.ko' kernel module needs to be built with support for
226 the Linux ABI compatibility layer. This is the case by default; as a
227 consequence, the 'nvidia.ko' kernel module requires the 'linux.ko' module to
230 Note: If you have no need for Linux ABI compatibility and do not wish to load
231 'linux.ko', you can build the 'nvidia.ko' kernel module without support for
232 the Linux ABI compatibility layer (see 'nv-freebsd.h' for details).
234 ______________________________________________________________________________
236 Chapter 4. Configuring X for the NVIDIA Driver
237 ______________________________________________________________________________
239 The X configuration file provides a means to configure the X server. This
240 section describes the settings necessary to enable the NVIDIA driver. A
241 comprehensive list of parameters is provided in Appendix F.
243 The NVIDIA Driver includes a utility called nvidia-xconfig, which is designed
244 to make editing the X configuration file easy. You can also edit it by hand.
247 4A. USING NVIDIA-XCONFIG TO CONFIGURE THE X SERVER
249 nvidia-xconfig will find the X configuration file and modify it to use the
250 NVIDIA X driver. In most cases, you can simply answer "Yes" when the installer
251 asks if it should run it. If you need to reconfigure your X server later, you
252 can run nvidia-xconfig again from a terminal. nvidia-xconfig will make a
253 backup copy of your configuration file before modifying it.
255 Note that the X server must be restarted for any changes to its configuration
258 More information about nvidia-xconfig can be found in the nvidia-xconfig
259 manual page by running.
266 4B. MANUALLY EDITING THE CONFIGURATION FILE
268 In April 2004 the X.Org Foundation released an X server based on the XFree86
269 server. While your release may use the X.Org X server, rather than XFree86,
270 the differences between the two should have no impact on NVIDIA FreeBSD users
273 o The X.Org configuration file is '/etc/X11/xorg.conf' while the XFree86
274 configuration file is '/etc/X11/XF86Config'. The files use the same
275 syntax. This document refers to both files as "the X config file".
277 o The X.Org log file is '/var/log/Xorg.#.log' while the XFree86 log file is
278 '/var/log/XFree86.#.log' (where '#' is the server number -- usually 0).
279 The format of the log files is nearly identical. This document refers to
280 both files as "the X log file".
282 In order for any changes to be read into the X server, you must edit the file
283 used by the server. While it is not unreasonable to simply edit both files, it
284 is easy to determine the correct file by searching for the line
286 (==) Using config file:
288 in the X log file. This line indicates the name of the X config file in use.
290 If you do not have a working X config file, there are a few different ways to
291 obtain one. A sample config file is included both with the XFree86
292 distribution and with the NVIDIA driver package (at
293 '/usr/X11R6/share/doc/NVIDIA_GLX-1.0/'). Tools for generating a config file
294 (such as 'xf86config') are generally included with FreeBSD. Additional
295 information on the X config syntax can be found in the XF86Config manual page
296 (`man XF86Config` or `man xorg.conf`).
298 If you have a working X config file for a different driver (such as the "nv"
299 or "vesa" driver), then simply edit the file as follows.
307 and replace it with the line:
311 Remove the following lines:
316 In the "Module" section of the file, add the line (if it does not already
321 There are numerous options that may be added to the X config file to tune the
322 NVIDIA X driver. See Appendix F for a complete list of these options.
324 Once you have completed these edits to the X config file, you may restart X
325 and begin using the accelerated OpenGL libraries. After restarting X, any
326 OpenGL application should automatically use the new NVIDIA libraries. (NOTE:
327 If you encounter any problems, see Chapter 6 for common problem diagnoses.)
329 ______________________________________________________________________________
331 Chapter 5. Frequently Asked Questions
332 ______________________________________________________________________________
334 This section provides answers to frequently asked questions associated with
335 the NVIDIA FreeBSD x86 Driver and its installation. Common problem diagnoses
336 can be found in Chapter 6 and tips for new users can be found in . Also,
337 detailed information for specific setups is provided in the Appendices.
342 Q. Where should I start when diagnosing display problems?
344 A. One of the most useful tools for diagnosing problems is the X log file in
345 '/var/log'. Lines that begin with "(II)" are information, "(WW)" are
346 warnings, and "(EE)" are errors. You should make sure that the correct
347 config file (i.e. the config file you are editing) is being used; look for
348 the line that begins with:
350 (==) Using config file:
352 Also make sure that the NVIDIA driver is being used, rather than the "nv"
353 or "vesa" driver. Search for
355 (II) LoadModule: "nvidia"
357 Lines from the driver should begin with:
363 Q. How can I increase the amount of data printed in the X log file?
365 A. By default, the NVIDIA X driver prints relatively few messages to stderr
366 and the X log file. If you need to troubleshoot, then it may be helpful to
367 enable more verbose output by using the X command line options -verbose and
368 -logverbose, which can be used to set the verbosity level for the 'stderr'
369 and log file messages, respectively. The NVIDIA X driver will output more
370 messages when the verbosity level is at or above 5 (X defaults to verbosity
371 level 1 for 'stderr' and level 3 for the log file). So, to enable verbose
372 messaging from the NVIDIA X driver to both the log file and 'stderr', you
373 could start X with the verbosity level set to 5, by doing the following
375 % startx -- -verbose 5 -logverbose 5
379 Q. I have read that the NVIDIA FreeBSD Driver is not a native driver, but sits
380 on top of the Linux ABI compatibility layer. Is this true?
382 A. No, the NVIDIA FreeBSD Graphics Driver is a native driver. It does provide
383 Linux OpenGL libraries in addition to the native, FreeBSD libraries to
384 enable users to run Linux OpenGL applications.
387 Q. Is the NVIDIA FreeBSD Accelerated Graphics Driver thread-safe?
389 A. This release is thread-safe on FreeBSD 5.3 or later systems making use of
390 the libpthread or libthr KSE threading libraries. On these systems, the
391 NVIDIA Linux ABI compatibility libraries are fully thread-safe as well.
394 Q. Why can't the Linux compatibility libraries correctly determine if they are
395 used in a multithreaded application?
397 A. The Linux compatibility libraries are not able to correctly determine if
398 they are used in a multithreaded application because the %gs segment
399 register is not initialized correctly for Linux compatibility.
401 The '__GL_SINGLE_THREADED' environment variable (set to "1") can be used to
402 work around this issue, but at the cost of thread-safeness.
405 Q. Why do applications that use DGA graphics fail?
407 A. The NVIDIA driver does not support the graphics component of the
408 XFree86-DGA (Direct Graphics Access) extension. Applications can use the
409 XDGASelectInput() function to acquire relative pointer motion, but
410 graphics-related functions such as XDGASetMode() and XDGAOpenFramebuffer()
413 The graphics component of XFree86-DGA is not supported because it requires
414 a CPU mapping of framebuffer memory. As graphics cards ship with increasing
415 quantities of video memory, the NVIDIA X driver has had to switch to a more
416 dynamic memory mapping scheme that is incompatible with DGA. Furthermore,
417 DGA does not cooperate with other graphics rendering libraries such as Xlib
418 and OpenGL because it accesses GPU resources directly.
420 NVIDIA recommends that applications use OpenGL or Xlib, rather than DGA,
421 for graphics rendering. Using rendering libraries other than DGA will yield
422 better performance and improve interoperability with other X applications.
425 Q. My kernel log contains messages that are prefixed with "Xid"; what do these
428 A. "Xid" messages indicate that a general GPU error occurred, most often due
429 to the driver misprogramming the GPU or to corruption of the commands sent
430 to the GPU. These messages provide diagnostic information that can be used
431 by NVIDIA to aid in debugging reported problems.
434 Q. On what NVIDIA hardware is the EXT_framebuffer_object OpenGL extension
437 A. EXT_framebuffer_object is supported on GeForce FX, Quadro FX, and newer
441 Q. I use the Coolbits overclocking interface to adjust my graphics card's
442 clock frequencies, but the defaults are reset whenever X is restarted. How
443 do I make my changes persistent?
445 A. Clock frequency settings are not saved/restored automatically by default to
446 avoid potential stability and other problems that may be encountered if the
447 chosen frequency settings differ from the defaults qualified by the
448 manufacturer. You can use the command line below in '~/.xinitrc' to
449 automatically apply custom clock frequency settings when the X server is
452 # nvidia-settings -a GPUOverclockingState=1 -a
453 GPU2DClockFreqs=<GPU>,<MEM> -a GPU3DClockFreqs=<GPU>,<MEM>
455 Here '<GPU>' and '<MEM>' are the desired GPU and video memory frequencies
456 (in MHz), respectively.
459 Q. Why is the refresh rate not reported correctly by utilities that use the
460 XRandR X extension (e.g., the GNOME "Screen Resolution Preferences" panel,
463 A. The XRandR X extension is not presently aware of multiple display devices
464 on a single X screen; it only sees the MetaMode bounding box, which may
465 contain one or more actual modes. This means that if multiple MetaModes
466 have the same bounding box, XRandR will not be able to distinguish between
469 In order to support DynamicTwinView, the NVIDIA X driver must make each
470 MetaMode appear to be unique to XRandR. Presently, the NVIDIA X driver
471 accomplishes this by using the refresh rate as a unique identifier.
473 You can use `nvidia-settings -q RefreshRate` to query the actual refresh
474 rate on each display device.
476 This behavior can be disabled by setting the X configuration option
477 "DynamicTwinView" to FALSE.
479 For details, see Chapter 10.
482 ______________________________________________________________________________
484 Chapter 6. Common Problems
485 ______________________________________________________________________________
487 This section provides solutions to common problems associated with the NVIDIA
490 Q. My X server fails to start, and my X log file contains the error:
492 (EE) NVIDIA(0): The NVIDIA kernel module does not appear to
493 (EE) NVIDIA(0): be receiving interrupts generated by the NVIDIA
495 (EE) NVIDIA(0): device PCI:x:x:x. Please see the COMMON PROBLEMS
496 (EE) NVIDIA(0): section in the README for additional information.
499 A. This can be caused by a variety of problems, such as PCI IRQ routing
500 errors, I/O APIC problems or conflicts with other devices sharing the IRQ
503 If possible, configure your system such that your graphics card does not
504 share its IRQ with other devices (try moving the graphics card to another
505 slot if applicable, unload/disable the driver(s) for the device(s) sharing
506 the card's IRQ, or remove/disable the device(s)).
509 Q. My X server fails to start, and my X log file contains the error:
511 (EE) NVIDIA(0): The interrupt for NVIDIA graphics device PCI:x:x:x
512 (EE) NVIDIA(0): appears to be edge-triggered. Please see the COMMON
513 (EE) NVIDIA(0): PROBLEMS section in the README for additional
517 A. An edge-triggered interrupt means that the kernel has programmed the
518 interrupt as edge-triggered rather than level-triggered in the Advanced
519 Programmable Interrupt Controller (APIC). Edge-triggered interrupts are not
520 intended to be used for sharing an interrupt line between multiple devices;
521 level-triggered interrupts are the intended trigger for such usage. When
522 using edge-triggered interrupts, it is common for device drivers using that
523 interrupt line to stop receiving interrupts. This would appear to the end
524 user as those devices no longer working, and potentially as a full system
525 hang. These problems tend to be more common when multiple devices are
526 sharing that interrupt line.
529 Q. X starts for me, but OpenGL applications terminate immediately.
531 A. If X starts but you have trouble with OpenGL, you most likely have a
532 problem with other libraries in the way, or there are stale symlinks. See
533 Appendix B for details.
535 You should also check that the correct extensions are present;
539 should show the "GLX" and "NV-GLX" extensions present. If these two
540 extensions are not present, then there is most likely a problem loading the
541 glx module, or it is unable to implicitly load GLcore. Check your X config
542 file and make sure that you are loading glx (see Chapter 4). If your X
543 config file is correct, then check the X log file for warnings/errors
544 pertaining to GLX. Also check that all of the necessary symlinks are in
545 place (refer to Appendix B).
548 Q. When Xinerama is enabled, my stereo glasses are shuttering only when the
549 stereo application is displayed on one specific X screen. When the
550 application is displayed on the other X screens, the stereo glasses stop
553 A. This problem occurs with DDC and "blue line" stereo glasses, that get the
554 stereo signal from one video port of the graphics card. When a X screen
555 does not display any stereo drawable the stereo signal is disabled on the
556 associated video port.
558 Forcing stereo flipping allows the stereo glasses to shutter continuously.
559 This can be done by enabling the OpenGL control "Force Stereo Flipping" in
560 nvidia-settings, or by setting the X configuration option
561 "ForceStereoFlipping" to "1".
564 Q. Stereo is not in sync across multiple displays.
566 A. There are two cases where this may occur. If the displays are attached to
567 the same GPU, and one of them is out of sync with the stereo glasses, you
568 will need to reconfigure your monitors to drive identical mode timings; see
569 Chapter 16 for details.
571 If the displays are attached to different GPUs, the only way to synchronize
572 stereo across the displays is with a G-Sync device, which is only supported
573 by certain Quadro cards. See Chapter 21 for details. This applies to
574 seperate GPUs on seperate cards as well as seperate GPUs on the same card,
575 such as Quadro FX 4500 X2. Note that the Quadro FX 4500 X2 only provides a
576 single DIN connector for stereo, tied to the bottommost GPU. In order to
577 synchronize onboard stereo on the other GPU you must use a G-Sync device.
580 Q. X fails to start, and during bootup time I get error messages
582 nvidia0: NVRM: NVIDIA REG resource alloc failed.
586 nvidia0: NVRM: NVIDIA IRQ resource alloc failed.
589 A. The system bios has not properly setup your graphics card; FreeBSD can't
590 currently setup PCI devices that the BIOS leaves unconfigured. Uncheck
591 "PNP-OS" in your system bios.
594 Q. X fails to start, and during bootup time I get the following error message:
596 nvidia0: NVRM: NVIDIA MEM resource alloc failed.
599 A. On certain FreeBSD kernels, it may be necessary to add the following line
600 to '/boot/loader.conf':
602 hw.pci.allow_unsupported_io_range="1"
604 This should allow the NVIDIA kernel module to attach.
607 Q. My X server fails to start, and my X log file contains the error:
609 (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!
612 A. Nothing will work if the NVIDIA kernel module does not function properly.
613 If you see anything in the X log file like
615 (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!
617 then there is most likely a problem with the NVIDIA kernel module.
619 The NVIDIA kernel module may print error messages indicating a problem --
620 to view these messages check the output of `dmesg`, '/var/log/messages', or
621 wherever syslog is directed to place kernel messages. These messages are
622 prepended with "NVRM".
625 Q. When I attempt to start `nvidia-settings`, I get an error message of the
628 Shared object "libgtk-x11-2.0.so.400" not found, required by
632 A. Due to differences between the gtk+-2.x ports packages included with
633 different FreeBSD 5.x releases, the prebuilt nvidia-settings binary shipped
634 with the NVIDIA driver may not work with FreeBSD releases more recent than
637 If you have a recent ports package of gtk+-2.x and gmake installed on your
638 system, you can build the nvidia-installer utility from source to solve
641 Download nvidia-settings-1.0.tar.gz (or the latest version) from
642 ftp://download.nvidia.com/XFree86/nvidia-settings You can then extract,
643 build and install it (to '/usr/local/bin') with:
649 Q. When I attempt to run `nvidia-xconfig` after the NVIDIA FreeBSD graphics
650 driver installation, I get an error message of the form:
652 nvidia-xconfig: Command not found.
655 A. Depending on the shell you are using, you may need to force it to recompute
656 its internal table of executable files present in the directories listed in
657 the '$PATH' variable. Assuming you are using the FreeBSD default shell you
658 can do so by issuing the command:
664 Q. When I attempt to start a Linux application as 'root', I get the error
667 NVIDIA: failed to execute '/sbin/modprobe': No such file or directory.
670 A. When initialized by an application executed with 'root' privileges, the
671 NVIDIA Linux OpenGL library, shipped with the NVIDIA FreeBSD graphics
672 driver for Linux ABI compatibility, will attempt to load the NVIDIA Linux
673 kernel module and fail because /sbin/modprobe is absent. You can work
674 around this problem by creating a symbolic link from '/usr/bin/true' to
675 '/compat/linux/sbin/modprobe':
677 % ln -s /usr/bin/true /compat/linux/sbin/modprobe
681 Q. My system runs, but seems unstable.
683 A. Your stability problems may be AGP-related. See Chapter 9 for details.
686 Q. OpenGL applications are running slowly
688 A. The application is probably using a different library that still remains on
689 your system, rather than the NVIDIA supplied OpenGL library. See Appendix B
693 Q. There are problems running Quake2.
695 A. Quake2 requires some minor setup to get it going. First, in the Quake2
696 directory, the install creates a symlink called 'libGL.so' that points at
697 'libMesaGL.so'. This symlink should be removed or renamed. Second, in order
698 to run Quake2 in OpenGL mode, you must type
700 % quake2 +set vid_ref glx +set gl_driver libGL.so
702 Quake2 does not seem to support any kind of full-screen mode, but you can
703 run your X server at the same resolution as Quake2 to emulate full-screen
707 Q. I am using either nForce of nForce2 internal graphics, and I see warnings
708 like this in my X log file:
710 Not using mode "1600x1200" (exceeds valid memory bandwidth usage)
713 A. Integrated graphics have more strict memory bandwidth limitations that
714 limit the resolution and refresh rate of the modes you request. To work
715 around this, you can reduce the maximum refresh rate by lowering the upper
716 value of the VertRefresh range in the 'Monitor' section of your X config
717 file. Though not recommended, you can disable the memory bandwidth test
718 with the NoBandWidthTest X config file option.
721 Q. X takes a long time to start (possibly several minutes).
723 A. Most of the X startup delay problems we have found are caused by incorrect
724 data in video BIOSes about what display devices are possibly connected or
725 what i2c port should be used for detection. You can work around these
726 problems with the X config option IgnoreDisplayDevices (see the description
730 Q. Fonts are incorrectly sized after installing the NVIDIA driver.
732 A. Incorrectly sized fonts are generally caused by incorrect DPI (Dots Per
733 Inch) information. You can check what X thinks the physical size of your
734 monitor is, by running:
736 % xdpyinfo | grep dimensions
738 This will report the size in pixels, and in millimeters.
740 If these numbers are wrong, you can correct them by modifying the X
741 server's DPI setting. See Appendix I for details.
744 Q. General problems with ALi chipsets
746 A. There are some known timing and signal integrity issues on ALi chipsets.
747 The following tips may help stabilize problematic ALI systems:
749 o Disable TURBO AGP MODE in the BIOS.
751 o When using a P5A upgrade to BIOS Revision 1002 BETA 2.
753 o When using 1007, 1007A or 1009 adjust the IO Recovery Time to 4
756 o AGP is disabled by default on some ALi chipsets (ALi1541, ALi1647) to
757 work around severe system stability problems with these chipsets. See
758 the comments for EnableALiAGP in 'nv-reg.h' to force AGP on anyway.
762 Q. Using GNOME configuration utilities, I am unable to get a resolution above
765 A. The installation of GNOME provided in operating systems such as Red Hat
766 Enterprise Linux 4 and Solaris 10 Update 2 contain several competing
767 interfaces for specifying resolution:
770 'System Settings' -> 'Display'
773 which will update the X configuration file, and
776 'Applications' -> 'Preferences' -> 'Screen Resolution'
779 which will update the per-user screen resolution using the XRandR
780 extension. Your desktop resolution will be limited to the smaller of the
781 two settings. Be sure to check the setting of each.
784 Q. X does not restore the VGA console when run on a TV. I get this error
785 message in my X log file:
787 Unable to initialize the X int10 module; the console may not be
788 restored correctly on your TV.
791 A. The NVIDIA X driver uses the X Int10 module to save and restore console
792 state on TV out, and will not be able to restore the console correctly if
793 it cannot use the Int10 module. If you have built the X server yourself,
794 please be sure you have built the Int10 module. If you are using a build of
795 the X server provided by your operating system and are missing the Int10
796 module, contact your operating system distributor.
799 Q. OpenGL applications don't work, and my X log file contains the error:
801 (EE) NVIDIA(0): Unable to map device node /dev/zero with read, write, and
802 (EE) NVIDIA(0): execute privileges. The GLX extension will be disabled
803 (EE) NVIDIA(0): on this X screen. Please see the COMMON PROBLEMS
804 (EE) NVIDIA(0): section in the README for more information.
807 A. The NVIDIA OpenGL driver must be able to map the '/dev/zero' device node
808 with read, write, and execute privileges in order to function correctly.
809 The driver needs this ability to allocate executable memory, which is used
810 for optimizations that require generating code at run-time. Currently, GLX
811 cannot run without these optimizations.
813 Check that your '/dev' filesystem is set up correctly. In particular,
814 mounting the '/dev' file system with the 'noexec' option will cause this to
815 happen. If you haven't changed the configuration of your '/dev' filesystem,
816 please contact your operating system distributor.
819 ______________________________________________________________________________
821 Chapter 7. Known Issues
822 ______________________________________________________________________________
824 The following problems still exist in this release and are in the process of
831 If you are using a notebook see the "Known Notebook Issues" in Chapter 15.
835 When FSAA is enabled (the __GL_FSAA_MODE environment variable is set to a
836 value that enables FSAA and a multisample visual is chosen), the rendering
837 may be corrupted when resizing the window.
839 libGL DSO finalizer and pthreads
841 When a multithreaded OpenGL application exits, it is possible for libGL's
842 DSO finalizer (also known as the destructor, or "_fini") to be called
843 while other threads are executing OpenGL code. The finalizer needs to free
844 resources allocated by libGL. This can cause problems for threads that are
845 still using these resources. Setting the environment variable
846 "__GL_NO_DSO_FINALIZER" to "1" will work around this problem by forcing
847 libGL's finalizer to leave its resources in place. These resources will
848 still be reclaimed by the operating system when the process exits. Note
849 that the finalizer is also executed as part of dlclose(3), so if you have
850 an application that dlopens(3) and dlcloses(3) libGL repeatedly,
851 "__GL_NO_DSO_FINALIZER" will cause libGL to leak resources until the
852 process exits. Using this option can improve stability in some
853 multithreaded applications, including Java3D applications.
855 XVideo and the Composite X extension
857 XVideo will not work correctly when Composite is enabled unless using
858 X.Org 7.1 or later. See Chapter 18.
860 This section describes problems that will not be fixed. Usually, the source of
861 the problem is beyond the control of NVIDIA. Following is the list of
864 Problems that Will Not Be Fixed
866 Gigabyte GA-6BX Motherboard
868 This motherboard uses a LinFinity regulator on the 3.3 V rail that is only
869 rated to 5 A -- less than the AGP specification, which requires 6 A. When
870 diagnostics or applications are running, the temperature of the regulator
871 rises, causing the voltage to the NVIDIA GPU to drop as low as 2.2 V.
872 Under these circumstances, the regulator cannot supply the current on the
873 3.3 V rail that the NVIDIA GPU requires.
875 This problem does not occur when the graphics card has a switching
876 regulator or when an external power supply is connected to the 3.3 V rail.
878 VIA KX133 and 694X Chip sets with AGP 2x
880 On Athlon motherboards with the VIA KX133 or 694X chip set, such as the
881 ASUS K7V motherboard, NVIDIA drivers default to AGP 2x mode to work around
882 insufficient drive strength on one of the signals.
884 Irongate Chip sets with AGP 1x
886 AGP 1x transfers are used on Athlon motherboards with the Irongate chipset
887 to work around a problem with signal integrity.
889 ALi chipsets, ALi1541 and ALi1647
891 On ALi1541 and ALi1647 chipsets, NVIDIA drivers disable AGP to work around
892 timing issues and signal integrity issues. See Chapter 6 for more
893 information on ALi chipsets.
895 NV-CONTROL versions 1.8 and 1.9
897 Version 1.8 of the NV-CONTROL X Extension introduced target types for
898 setting and querying attributes as well as receiving event notification on
899 targets. Targets are objects like X Screens, GPUs and G-Sync devices.
900 Previously, all attributes were described relative to an X Screen. These
901 new bits of information (target type and target id) were packed in a
902 non-compatible way in the protocol stream such that addressing X Screen 1
903 or higher would generate an X protocol error when mixing NV-CONTROL client
906 This packing problem has been fixed in the NV-CONTROL 1.10 protocol,
907 making it possible for the older (1.7 and prior) clients to communicate
908 with NV-CONTROL 1.10 servers. Furthermore, the NV-CONTROL 1.10 client
909 library has been updated to accommodate the target protocol packing bug
910 when communicating with a 1.8 or 1.9 NV-CONTROL server. This means that
911 the NV-CONTROL 1.10 client library should be able to communicate with any
912 version of the NV-CONTROL server.
914 NVIDIA recommends that NV-CONTROL client applications relink with version
915 1.10 or later of the NV-CONTROL client library (libXNVCtrl.a, in the
916 nvidia-settings-1.0.tar.gz tarball). The version of the client library can
917 be determined by checking the NV_CONTROL_MAJOR and NV_CONTROL_MINOR
918 definitions in the accompanying nv_control.h.
920 The only web released NVIDIA FreeBSD driver that is affected by this
921 problem (i.e., the only driver to use either version 1.8 or 1.9 of the
922 NV-CONTROL X extension) is 1.0-8756.
925 ______________________________________________________________________________
927 Chapter 8. Specifying OpenGL Environment Variable Settings
928 ______________________________________________________________________________
931 8A. FULL SCENE ANTIALIASING
933 Antialiasing is a technique used to smooth the edges of objects in a scene to
934 reduce the jagged "stairstep" effect that sometimes appears. Full-scene
935 antialiasing is supported on GeForce or newer hardware. By setting the
936 appropriate environment variable, you can enable full-scene antialiasing in
937 any OpenGL application on these GPUs.
939 Several antialiasing methods are available and you can select between them by
940 setting the __GL_FSAA_MODE environment variable appropriately. Note that
941 increasing the number of samples taken during FSAA rendering may decrease
944 The following tables describe the possible values for __GL_FSAA_MODE and the
945 effects that they have on various NVIDIA GPUs.
949 __GL_FSAA_MODE GeForce, GeForce2, Quadro, and Quadro2 Pro
950 --------------- ------------------------------------------------------
954 3 1.5 x 1.5 Supersampling
955 4 2 x 2 Supersampling
963 __GL_FSAA_MODE GeForce4 MX, GeForce4 4xx Go, Quadro4 380,550,580
965 --------------- ------------------------------------------------------
967 1 2x Bilinear Multisampling
968 2 2x Quincunx Multisampling
970 4 2 x 2 Supersampling
978 __GL_FSAA_MODE GeForce3, Quadro DCC, GeForce4 Ti, GeForce4 4200 Go,
979 and Quadro4 700,750,780,900,980 XGL
980 --------------- ------------------------------------------------------
982 1 2x Bilinear Multisampling
983 2 2x Quincunx Multisampling
985 4 4x Bilinear Multisampling
986 5 4x Gaussian Multisampling
987 6 2x Bilinear Multisampling by 4x Supersampling
993 __GL_FSAA_MODE GeForce FX, GeForce 6xxx, GeForce 7xxx, Quadro FX
994 --------------- ------------------------------------------------------
996 1 2x Bilinear Multisampling
997 2 2x Quincunx Multisampling
999 4 4x Bilinear Multisampling
1000 5 4x Gaussian Multisampling
1001 6 2x Bilinear Multisampling by 4x Supersampling
1002 7 4x Bilinear Multisampling by 4x Supersampling
1003 8 4x Bilinear Multisampling by 2x Supersampling
1004 (available on GeForce FX and later GPUs; not
1005 available on Quadro GPUs)
1010 __GL_FSAA_MODE GeForce 8xxx, G8xGL
1011 --------------- ------------------------------------------------------
1013 1 2x Bilinear Multisampling
1016 4 4x Bilinear Multisampling
1019 7 4x Bilinear Multisampling by 4x Supersampling
1021 9 8x Bilinear Multisampling
1025 13 8x Bilinear Multisampling by 4x Supersampling
1029 8B. ANISOTROPIC TEXTURE FILTERING
1031 Automatic anisotropic texture filtering can be enabled by setting the
1032 environment variable __GL_LOG_MAX_ANISO. The possible values are:
1034 __GL_LOG_MAX_ANISO Filtering Type
1035 ---------------------------------- ----------------------------------
1036 0 No anisotropic filtering
1037 1 2x anisotropic filtering
1038 2 4x anisotropic filtering
1039 3 8x anisotropic filtering
1040 4 16x anisotropic filtering
1042 4x and greater are only available on GeForce3 or newer GPUs; 16x is only
1043 available on GeForce 6800 or newer GPUs.
1048 Setting the environment variable __GL_SYNC_TO_VBLANK to a non-zero value will
1049 force glXSwapBuffers to sync to your monitor's vertical refresh (perform a
1050 swap only during the vertical blanking period).
1052 When using __GL_SYNC_TO_VBLANK with TwinView, OpenGL can only sync to one of
1053 the display devices; this may cause tearing corruption on the display device
1054 to which OpenGL is not syncing. You can use the environment variable
1055 __GL_SYNC_DISPLAY_DEVICE to specify to which display device OpenGL should
1056 sync. You should set this environment variable to the name of a display
1057 device; for example "CRT-1". Look for the line "Connected display device(s):"
1058 in your X log file for a list of the display devices present and their names.
1059 You may also find it useful to review Chapter 10 "Configuring Twinview" and
1060 the section on Ensuring Identical Mode Timings in Chapter 16.
1063 8D. DISABLING CPU-SPECIFIC FEATURES
1065 Setting the environment variable __GL_FORCE_GENERIC_CPU to a non-zero value
1066 will inhibit the use of CPU-specific features such as MMX, SSE, or 3DNOW!. Use
1067 of this option may result in performance loss.
1070 8E. CONTROLLING THE SORTING OF OPENGL FBCONFIGS
1072 The NVIDIA GLX implementation sorts FBConfigs returned by glXChooseFBConfig()
1073 as described in the GLX specification. To disable this behavior set
1074 __GL_SORT_FBCONFIGS to 0 (zero), then FBConfigs will be returned in the order
1075 they were received from the X server. To examine the order in which FBConfigs
1076 are returned by the X server run:
1078 nvidia-settings --glxinfo
1080 This option may be be useful to work around problems in which applications
1081 pick an unexpected FBConfig.
1084 8F. OPENGL YIELD BEHAVIOR
1086 There are several cases where the NVIDIA OpenGL driver needs to wait for
1087 external state to change before continuing. To avoid consuming too much CPU
1088 time in these cases, the driver will sometimes yield so the kernel can
1089 schedule other processes to run while the driver waits. For example, when
1090 waiting for free space in a command buffer, if the free space has not become
1091 available after a certain number of iterations, the driver will yield before
1092 it continues to loop.
1094 By default, the driver calls sched_yield() to do this. However, this can cause
1095 the calling process to be scheduled out for a relatively long period of time
1096 if there are other, same-priority processes competing for time on the CPU. One
1097 example of this is when an OpenGL-based composite manager is moving and
1098 repainting a window and the X server is trying to update the window as it
1099 moves, which are both CPU-intensive operations.
1101 You can use the __GL_YIELD environment variable to work around these
1102 scheduling problems. This variable allows the user to specify what the driver
1103 should do when it wants to yield. The possible values are:
1106 --------------- ------------------------------------------------------
1107 <unset> By default, OpenGL will call sched_yield() to yield.
1108 "NOTHING" OpenGL will never yield.
1109 "USLEEP" OpenGL will call usleep(0) to yield.
1113 8G. CONTROLLING WHICH OPENGL FBCONFIGS ARE AVAILABLE
1115 The NVIDIA GLX implementation will hide FBConfigs that are associated with a
1116 32-bit ARGB visual when the XLIB_SKIP_ARGB_VISUALS environment variable is
1117 defined. This matches the behavior of libX11, which will hide those visuals
1118 from XGetVisualInfo and XMatchVisualInfo. This environment variable is useful
1119 when applications are confused by the presence of these FBConfigs.
1121 ______________________________________________________________________________
1123 Chapter 9. Configuring AGP
1124 ______________________________________________________________________________
1126 There are several choices for configuring the NVIDIA kernel module's use of
1127 AGP: you can choose to either use the NVIDIA AGP module (NVAGP), or the AGP
1128 module that comes with the FreeBSD kernel (AGPGART). This is controlled
1129 through the "NvAGP" option in your X config file:
1131 Option "NvAgp" "0" ... disables AGP support
1132 Option "NvAgp" "1" ... use NVAGP, if possible
1133 Option "NvAgp" "2" ... use AGPGART, if possible
1134 Option "NvAGP" "3" ... try AGPGART; if that fails, try NVAGP
1136 Unlike other operating systems such as Linux, this option is not the only
1137 controlling factor at this point; because of known problems, 'nvidia.ko' is
1138 built without support for FreeBSD's AGP driver by default. This behavior can
1139 be changed, see 'nv-freebsd.h' for details.
1141 Note that if you built nvidia.ko with support for the FreeBSD driver it will
1142 not load unless 'agp.ko' is loaded. 'agp.ko' is special in that you can not
1143 load it after the system boot is complete, you need to append the following
1144 line to '/boot/loader.conf' to make sure it is pre-loaded:
1146 # -- load FreeBSD AGP GART driver -- #
1149 Also note that if 'agp.ko' is loaded, it could conflict with the NVIDIA AGP
1150 GART driver (NvAGP), resulting in stability problems; for this reason, the
1151 NVIDIA driver will abort NvAGP initialization when it detects 'agp.ko'.
1153 Current FreeBSD releases are shipped with 'agp.ko' built into the kernel; in
1154 order to allow NvAGP to work, the kernel can be rebuilt without 'device agp'
1155 or the following entry added to '/boot/device.hints':
1157 hint.agp.0.disabled="1"
1159 When built with support for the FreeBSD AGP driver, 'nvidia.ko' will fall back
1160 to using NvAGP when it doesn't detect 'agp.ko' (this will be the case when
1161 'agp.ko' does not support your AGP chipset or was explicitely disabled with
1164 It is highly recommended that you use the NVIDIA AGP driver.
1166 The following AGP chipsets are supported by the NVIDIA AGP driver; for all
1167 other chipsets it is recommended that you use the AGPGART module.
1169 Supported AGP Chipsets
1170 ----------------------------------------------------------------------
1174 Intel 815 ("Solano")
1175 Intel 820 ("Camino")
1177 Intel 840 ("Carmel")
1178 Intel 845 ("Brookdale")
1180 Intel 850 ("Tehama")
1182 Intel 860 ("Colusa")
1183 Intel 865G ("Springdale")
1184 Intel 875P ("Canterwood")
1185 Intel E7205 ("Granite Bay")
1186 Intel E7505 ("Placer")
1187 AMD 751 ("Irongate")
1205 Micron SAMDDR ("Samurai")
1206 Micron SCIDDR ("Scimitar")
1235 If you are experiencing AGP stability problems, you should be aware of the
1238 Additional AGP Information
1240 AGP drive strength BIOS setting (Via-based motherboards)
1242 Many Via-based motherboards allow adjusting the AGP drive strength in the
1243 system BIOS. The setting of this option largely affects system stability,
1244 the range between 0xEA and 0xEE seems to work best for NVIDIA hardware.
1245 Setting either nibble to 0xF generally results in severe stability
1248 If you decide to experiment with this, you need to be aware of the fact
1249 that you are doing so at your own risk and that you may render your system
1250 unbootable with improper settings until you reset the setting to a working
1251 value (w/ a PCI graphics card or by resetting the BIOS to its default
1256 Make sure you have the latest system BIOS provided by the motherboard
1259 On ALi1541 and ALi1647 chipsets, NVIDIA drivers disable AGP to work around
1260 timing and signal integrity problems. You can force AGP to be enabled on
1261 these chipsets by setting NVreg_EnableALiAGP to 1. Note that this may
1262 cause the system to become unstable.
1264 Early system BIOS revisions for the ASUS A7V8X-X KT400 motherboard
1265 misconfigure the chipset when an AGP 2.x graphics card is installed; if X
1266 hangs on your ASUS KT400 system with NvAGP enabled and the installed
1267 graphics card is not an AGP 8x device, make sure that you have the latest
1268 system BIOS installed.
1271 ______________________________________________________________________________
1273 Chapter 10. Configuring TwinView
1274 ______________________________________________________________________________
1276 TwinView is a mode of operation where two display devices (digital flat
1277 panels, CRTs, and TVs) can display the contents of a single X screen in any
1278 arbitrary configuration. This method of multiple monitor use has several
1279 distinct advantages over other techniques (such as Xinerama):
1282 o A single X screen is used. The NVIDIA driver conceals all information
1283 about multiple display devices from the X server; as far as X is
1284 concerned, there is only one screen.
1286 o Both display devices share one frame buffer. Thus, all the functionality
1287 present on a single display (e.g., accelerated OpenGL) is available with
1290 o No additional overhead is needed to emulate having a single desktop.
1293 If you are interested in using each display device as a separate X screen, see
1297 10A. X CONFIG TWINVIEW OPTIONS
1299 To enable TwinView, you must specify the following option in the Device
1300 section of your X Config file:
1304 You may also use any of the following options, though they are not required:
1306 Option "MetaModes" "<list of MetaModes>"
1308 Option "SecondMonitorHorizSync" "<hsync range(s)>"
1309 Option "SecondMonitorVertRefresh" "<vrefresh range(s)>"
1311 Option "HorizSync" "<hsync range(s)>"
1312 Option "VertRefresh" "<vrefresh range(s)>"
1314 Option "TwinViewOrientation" "<relationship of head 1 to head 0>"
1315 Option "ConnectedMonitor" "<list of connected display devices>"
1317 See detailed descriptions of each option below.
1319 Alternatively, you can enable TwinView by running
1321 nvidia-xconfig --twinview
1323 and restarting your X server. Or, you can configure TwinView dynamically in
1324 the "Display Configuration" page in nvidia-settings.
1327 10B. DETAILED DESCRIPTION OF OPTIONS
1332 This option is required to enable TwinView; without it, all other TwinView
1333 related options are ignored.
1335 SecondMonitorHorizSync
1336 SecondMonitorVertRefresh
1338 You specify the constraints of the second monitor through these options.
1339 The values given should follow the same convention as the "HorizSync" and
1340 "VertRefresh" entries in the Monitor section. As the XF86Config man page
1341 explains it: the ranges may be a comma separated list of distinct values
1342 and/or ranges of values, where a range is given by two distinct values
1343 separated by a dash. The HorizSync is given in kHz, and the VertRefresh is
1346 These options are normally not needed: by default, the NVIDIA X driver
1347 retrieves the valid frequency ranges from the display device's EDID (see
1348 Appendix F for a description of the "UseEdidFreqs" option). The
1349 SecondMonitor options will override any frequency ranges retrieved from
1355 Which display device is "first" and which is "second" is often unclear.
1356 For this reason, you may use these options instead of the SecondMonitor
1357 versions. With these options, you can specify a semicolon-separated list
1358 of frequency ranges, each optionally prepended with a display device name.
1361 Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70"
1362 Option "VertRefresh" "CRT-0: 60-120; DFP-0: 60"
1364 See Appendix G on Display Device Names for more information.
1366 These options are normally not needed: by default, the NVIDIA X driver
1367 retrieves the valid frequency ranges from the display device's EDID (see
1368 Appendix F for a description of the "UseEdidFreqs" option). The
1369 "HorizSync" and "VertRefresh" options override any frequency ranges
1370 retrieved from the EDID or any frequency ranges specified with the
1371 "SecondMonitorHorizSync" and "SecondMonitorVertRefresh" options.
1375 MetaModes are "containers" that store information about what mode should
1376 be used on each display device at any given time. Even if only one display
1377 device is actively in use, the NVIDIA X driver always uses a MetaMode to
1378 encapsulate the mode information per display device, so that it can
1379 support dynamically enabling TwinView.
1381 Multiple MetaModes list the combinations of modes and the sequence in
1382 which they should be used. When the NVIDIA driver tells X what modes are
1383 available, it is really the minimal bounding box of the MetaMode that is
1384 communicated to X, while the "per display device" mode is kept internal to
1385 the NVIDIA driver. In MetaMode syntax, modes within a MetaMode are comma
1386 separated, and multiple MetaModes are separated by semicolons. For
1389 "<mode name 0>, <mode name 1>; <mode name 2>, <mode name 3>"
1391 Where <mode name 0> is the name of the mode to be used on display device 0
1392 concurrently with <mode name 1> used on display device 1. A mode switch
1393 will then cause <mode name 2> to be used on display device 0 and <mode
1394 name 3> to be used on display device 1. Here is an example MetaMode:
1396 Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768"
1398 If you want a display device to not be active for a certain MetaMode, you
1399 can use the mode name "NULL", or simply omit the mode name entirely:
1401 "1600x1200, NULL; NULL, 1024x768"
1405 "1600x1200; , 1024x768"
1407 Optionally, mode names can be followed by offset information to control
1408 the positioning of the display devices within the virtual screen space;
1411 "1600x1200 +0+0, 1024x768 +1600+0; ..."
1413 Offset descriptions follow the conventions used in the X "-geometry"
1414 command line option; i.e., both positive and negative offsets are valid,
1415 though negative offsets are only allowed when a virtual screen size is
1416 explicitly given in the X config file.
1418 When no offsets are given for a MetaMode, the offsets will be computed
1419 following the value of the TwinViewOrientation option (see below). Note
1420 that if offsets are given for any one of the modes in a single MetaMode,
1421 then offsets will be expected for all modes within that single MetaMode;
1422 in such a case offsets will be assumed to be +0+0 when not given.
1424 When not explicitly given, the virtual screen size will be computed as the
1425 the bounding box of all MetaMode bounding boxes. MetaModes with a bounding
1426 box larger than an explicitly given virtual screen size will be discarded.
1428 A MetaMode string can be further modified with a "Panning Domain"
1429 specification; e.g.,
1431 "1024x768 @1600x1200, 800x600 @1600x1200"
1433 A panning domain is the area in which a display device's viewport will be
1434 panned to follow the mouse. Panning actually happens on two levels with
1435 TwinView: first, an individual display device's viewport will be panned
1436 within its panning domain, as long as the viewport is contained by the
1437 bounding box of the MetaMode. Once the mouse leaves the bounding box of
1438 the MetaMode, the entire MetaMode (i.e., all display devices) will be
1439 panned to follow the mouse within the virtual screen. Note that individual
1440 display devices' panning domains default to being clamped to the position
1441 of the display devices' viewports, thus the default behavior is just that
1442 viewports remain "locked" together and only perform the second type of
1445 The most beneficial use of panning domains is probably to eliminate dead
1446 areas -- regions of the virtual screen that are inaccessible due to
1447 display devices with different resolutions. For example:
1449 "1600x1200, 1024x768"
1451 produces an inaccessible region below the 1024x768 display. Specifying a
1452 panning domain for the second display device:
1454 "1600x1200, 1024x768 @1024x1200"
1456 provides access to that dead area by allowing you to pan the 1024x768
1457 viewport up and down in the 1024x1200 panning domain.
1459 Offsets can be used in conjunction with panning domains to position the
1460 panning domains in the virtual screen space (note that the offset
1461 describes the panning domain, and only affects the viewport in that the
1462 viewport must be contained within the panning domain). For example, the
1463 following describes two modes, each with a panning domain width of 1900
1464 pixels, and the second display is positioned below the first:
1466 "1600x1200 @1900x1200 +0+0, 1024x768 @1900x768 +0+1200"
1468 Because it is often unclear which mode within a MetaMode will be used on
1469 each display device, mode descriptions within a MetaMode can be prepended
1470 with a display device name. For example:
1472 "CRT-0: 1600x1200, DFP-0: 1024x768"
1474 If no MetaMode string is specified, then the X driver uses the modes
1475 listed in the relevant "Display" subsection, attempting to place matching
1476 modes on each display device.
1480 This option controls the positioning of the second display device relative
1481 to the first within the virtual X screen, when offsets are not explicitly
1482 given in the MetaModes. The possible values are:
1484 "RightOf" (the default)
1490 When "Clone" is specified, both display devices will be assigned an offset
1493 Because it is often unclear which display device is "first" and which is
1494 "second", TwinViewOrientation can be confusing. You can further clarify
1495 the TwinViewOrientation with display device names to indicate which
1496 display device is positioned relative to which display device. For
1499 "CRT-0 LeftOf DFP-0"
1504 With this option you can override what the NVIDIA kernel module detects is
1505 connected to your graphics card. This may be useful, for example, if any
1506 of your display devices do not support detection using Display Data
1507 Channel (DDC) protocols. Valid values are a comma-separated list of
1508 display device names; for example:
1514 WARNING: this option overrides what display devices are detected by the
1515 NVIDIA kernel module, and is very seldom needed. You really only need this
1516 if a display device is not detected, either because it does not provide
1517 DDC information, or because it is on the other side of a KVM
1518 (Keyboard-Video-Mouse) switch. In most other cases, it is best not to
1519 specify this option.
1522 Just as in all X config entries, spaces are ignored and all entries are case
1526 10C. DYNAMIC TWINVIEW
1528 Using the NV-CONTROL X extension, the display devices in use by an X screen,
1529 the mode pool for each display device, and the MetaModes for each X screen can
1530 be dynamically manipulated. The "Display Configuration" page in
1531 nvidia-settings uses this functionality to modify the MetaMode list and then
1532 uses XRandR to switch between MetaModes. This gives the ability to dynamically
1535 The details of how this works are documented in the nv-control-dpy.c sample
1536 NV-CONTROL client in the nvidia-settings source tarball.
1538 Because the NVIDIA X driver can now transition into and out of TwinView
1539 dynamically, MetaModes are always used internally by the NVIDIA X driver,
1540 regardless of how many display devices are currently in use by the X screen
1541 and regardless of whether the TwinView X configuration option was specified.
1543 One implication of this implementation is that each MetaMode must be uniquely
1544 identifiable to the XRandR X extension. Unfortunately, two MetaModes with the
1545 same bounding box will look the same to XRandR. For example, two MetaModes
1546 with different orientations:
1548 "CRT: 1600x1200 +0+0, DFP: 1600x1200 +1600+0"
1549 "CRT: 1600x1200 +1600+0, DFP: 1600x1200 +0+0"
1551 will look identical to the XRandR or XF86VidMode X extensions, because they
1552 have the same total size (3200x1200), and nvidia-settings would not be able to
1553 use XRandR to switch between these MetaModes. To work around this limitation,
1554 the NVIDIA X driver "lies" about the refresh rate of each MetaMode, using the
1555 refresh rate of the MetaMode as a unique identifier.
1557 The XRandR extension is currently being redesigned by the X.Org community, so
1558 the refresh rate workaround may be removed at some point in the future. This
1559 workaround can also be disabled by setting the "DynamicTwinView" X
1560 configuration option to FALSE, which will disable NV-CONTROL support for
1561 manipulating MetaModes, but will cause the XRandR and XF86VidMode visible
1562 refresh rate to be accurate.
1565 FREQUENTLY ASKED TWINVIEW QUESTIONS
1567 Q. Nothing gets displayed on my second monitor; what is wrong?
1569 A. Monitors that do not support monitor detection using Display Data Channel
1570 (DDC) protocols (this includes most older monitors) are not detectable by
1571 your NVIDIA card. You need to explicitly tell the NVIDIA X driver what you
1572 have connected using the "ConnectedMonitor" option; e.g.,
1574 Option "ConnectedMonitor" "CRT, CRT"
1578 Q. Will window managers be able to appropriately place windows (e.g., avoiding
1579 placing windows across both display devices, or in inaccessible regions of
1580 the virtual desktop)?
1582 A. Yes. The NVIDIA X driver provides a Xinerama extension that X clients (such
1583 as window managers) can use to discover the current TwinView configuration.
1584 Note that the Xinerama protocol provides no way to notify clients when a
1585 configuration change occurs, so if you modeswitch to a different MetaMode,
1586 your window manager will still think you have the previous configuration.
1587 Using the Xinerama extension, in conjunction with the XF86VidMode extension
1588 to get modeswitch events, window managers should be able to determine the
1589 TwinView configuration at any given time.
1591 Unfortunately, the data provided by XineramaQueryScreens() appears to
1592 confuse some window managers; to work around such broken window mangers,
1593 you can disable communication of the TwinView screen layout with the
1594 "NoTwinViewXineramaInfo" X config Option (see Appendix F for details).
1596 The order that display devices are reported in via the TwinView Xinerama
1597 information can be configured with the TwinViewXineramaInfoOrder X
1598 configuration option.
1600 Be aware that the NVIDIA driver cannot provide the Xinerama extension if
1601 the X server's own Xinerama extension is being used. Explicitly specifying
1602 Xinerama in the X config file or on the X server commandline will prohibit
1603 NVIDIA's Xinerama extension from installing, so make sure that the X
1604 server's log file does not contain:
1606 (++) Xinerama: enabled
1608 if you want the NVIDIA driver to be able to provide the Xinerama extension
1611 Another solution is to use panning domains to eliminate inaccessible
1612 regions of the virtual screen (see the MetaMode description above).
1614 A third solution is to use two separate X screens, rather than use
1615 TwinView. See Chapter 12.
1618 Q. Why can I not get a resolution of 1600x1200 on the second display device
1619 when using a GeForce2 MX?
1621 A. Because the second display device on the GeForce2 MX was designed to be a
1622 digital flat panel, the Pixel Clock for the second display device is only
1623 150 MHz. This effectively limits the resolution on the second display
1624 device to somewhere around 1280x1024 (for a description of how Pixel Clock
1625 frequencies limit the programmable modes, see the XFree86 Video Timings
1626 HOWTO). This constraint is not present on GeForce4 or GeForce FX GPUs --
1627 the maximum pixel clock is the same on both heads.
1630 Q. Do video overlays work across both display devices?
1632 A. Hardware video overlays only work on the first display device. The current
1633 solution is that blitted video is used instead on TwinView.
1636 Q. How are virtual screen dimensions determined in TwinView?
1638 A. After all requested modes have been validated, and the offsets for each
1639 MetaMode's viewports have been computed, the NVIDIA driver computes the
1640 bounding box of the panning domains for each MetaMode. The maximum bounding
1641 box width and height is then found.
1643 Note that one side effect of this is that the virtual width and virtual
1644 height may come from different MetaModes. Given the following MetaMode
1647 "1600x1200,NULL; 1024x768+0+0, 1024x768+0+768"
1649 the resulting virtual screen size will be 1600 x 1536.
1652 Q. Can I play full screen games across both display devices?
1654 A. Yes. While the details of configuration will vary from game to game, the
1655 basic idea is that a MetaMode presents X with a mode whose resolution is
1656 the bounding box of the viewports for that MetaMode. For example, the
1659 Option "MetaModes" "1024x768,1024x768; 800x600,800x600"
1660 Option "TwinViewOrientation" "RightOf"
1662 produce two modes: one whose resolution is 2048x768, and another whose
1663 resolution is 1600x600. Games such as Quake 3 Arena use the VidMode
1664 extension to discover the resolutions of the modes currently available. To
1665 configure Quake 3 Arena to use the above MetaMode string, add the following
1666 to your q3config.cfg file:
1668 seta r_customaspect "1"
1669 seta r_customheight "600"
1670 seta r_customwidth "1600"
1671 seta r_fullscreen "1"
1674 Note that, given the above configuration, there is no mode with a
1675 resolution of 800x600 (remember that the MetaMode "800x600, 800x600" has a
1676 resolution of 1600x600"), so if you change Quake 3 Arena to use a
1677 resolution of 800x600, it will display in the lower left corner of your
1678 screen, with the rest of the screen grayed out. To have single head modes
1679 available as well, an appropriate MetaMode string might be something like:
1681 "800x600,800x600; 1024x768,NULL; 800x600,NULL; 640x480,NULL"
1683 More precise configuration information for specific games is beyond the
1684 scope of this document, but the above examples coupled with numerous online
1685 sources should be enough to point you in the right direction.
1688 ______________________________________________________________________________
1690 Chapter 11. Configuring GLX in Xinerama
1691 ______________________________________________________________________________
1693 The NVIDIA FreeBSD Driver supports GLX when Xinerama is enabled on similar
1694 GPUs. The Xinerama extension takes multiple physical X screens (possibly
1695 spanning multiple GPUs), and binds them into one logical X screen. This allows
1696 windows to be dragged between GPUs and to span across multiple GPUs. The
1697 NVIDIA driver supports hardware accelerated OpenGL rendering across all NVIDIA
1698 GPUs when Xinerama is enabled.
1700 To configure Xinerama
1702 1. Configure multiple X screens (refer to the XF86Config(5x) or
1703 xorg.conf(5x) manpages for details).
1705 2. Enable Xinerama by adding the line
1707 Option "Xinerama" "True"
1709 to the "ServerFlags" section of your X config file.
1714 o Using identical GPUs is recommended. Some combinations of non-identical,
1715 but similar, GPUs are supported. If a GPU is incompatible with the rest
1716 of a Xinerama desktop then no OpenGL rendering will appear on the screens
1717 driven by that GPU. Rendering will still appear normally on screens
1718 connected to other supported GPUs. In this situation the X log file will
1719 include a message of the form:
1723 (WW) NVIDIA(2): The GPU driving screen 2 is incompatible with the rest of
1724 (WW) NVIDIA(2): the GPUs composing the desktop. OpenGL rendering will
1725 (WW) NVIDIA(2): be disabled on screen 2.
1729 o The NVIDIA X driver must be used for all X screens in the server.
1731 o Only the intersection of capabilities across all GPUs will be advertised.
1733 The maximum OpenGL viewport size depends on the hardware used, and is
1734 described by the following table. If an OpenGL window is larger than the
1735 maximum viewport, regions beyond the viewport will be blank.
1737 OpenGL Viewport Maximums in Xinerama
1739 GeForce GPUs before GeForce 8: 4096 x 4096 pixels
1740 GeForce 8 and newer GPUs: 8192 x 8192 pixels
1741 Quadro: as large as the Xinerama
1745 o X configuration options that affect GLX operation (e.g.: stereo,
1746 overlays) should be set consistently across all X screens in the X
1752 o Versions of XFree86 prior to 4.5 and versions of X.Org prior to 6.8.0
1753 lack the required interfaces to properly implement overlays with the
1754 Xinerama extension. On earlier server versions mixing overlays and
1755 Xinerama will result in rendering corruption. If you are using the
1756 Xinerama extension with overlays, it is recommended that you upgrade to
1757 XFree86 4.5, X.Org 6.8.0, or newer.
1760 ______________________________________________________________________________
1762 Chapter 12. Configuring Multiple X Screens on One Card
1763 ______________________________________________________________________________
1765 GPUs that support TwinView (Chapter 10) can also be configured to treat each
1766 connected display device as a separate X screen.
1768 While there are several disadvantages to this approach as compared to TwinView
1769 (e.g.: windows cannot be dragged between X screens, hardware accelerated
1770 OpenGL cannot span the two X screens), it does offer several advantages over
1773 o If each display device is a separate X screen, then properties that may
1774 vary between X screens may vary between displays (e.g.: depth, root
1777 o Hardware that can only be used on one display at a time (e.g.: video
1778 overlays, hardware accelerated RGB overlays), and which consequently
1779 cannot be used at all when in TwinView, can be exposed on the first X
1780 screen when each display is a separate X screen.
1782 o TwinView is a fairly new feature. X has historically used one screen per
1786 To configure two separate X screens to share one graphics card, here is what
1787 you will need to do:
1789 First, create two separate Device sections, each listing the BusID of the
1790 graphics card to be shared and listing the driver as "nvidia", and assign each
1794 Identifier "nvidia0"
1796 # Edit the BusID with the location of your graphics card
1802 Identifier "nvidia1"
1804 # Edit the BusID with the location of your graphics card
1809 Then, create two Screen sections, each using one of the Device sections:
1812 Identifier "Screen0"
1816 Subsection "Display"
1818 Modes "1600x1200" "1024x768" "800x600" "640x480"
1823 Identifier "Screen1"
1827 Subsection "Display"
1829 Modes "1600x1200" "1024x768" "800x600" "640x480"
1833 (Note: You'll also need to create a second Monitor section) Finally, update
1834 the ServerLayout section to use and position both Screen sections:
1836 Section "ServerLayout"
1839 Screen 1 "Screen1" leftOf "Screen0"
1843 For further details, refer to the XF86Config(5x) or xorg.conf(5x) manpages.
1845 ______________________________________________________________________________
1847 Chapter 13. Configuring TV-Out
1848 ______________________________________________________________________________
1850 NVIDIA GPU-based graphics cards with a TV-Out connector can use a television
1851 as another display device (the same way that it would use a CRT or digital
1852 flat panel). The TV can be used by itself, or in conjunction with another
1853 display device in a TwinView or multiple X screen configuration. If a TV is
1854 the only display device connected to your graphics card, it will be used as
1855 the primary display when you boot your system (i.e. the console will come up
1856 on the TV just as if it were a CRT).
1858 The NVIDIA X driver populates the mode pool for the TV with all the mode sizes
1859 that the driver supports with the given TV standard and the TV encoder on the
1860 graphics card. These modes are given names that correspond to their
1861 resolution; e.g., "800x600".
1863 Because these TV modes only depend on the TV encoder and the TV standard, TV
1864 modes do not go through normal mode validation. The X configuration options
1865 HorizSync and VertRefresh are not used for TV mode validation.
1867 Additionally, the NVIDIA driver contains a hardcoded list of mode sizes that
1868 it can drive for each combination of TV encoder and TV standard. Therefore,
1869 custom modelines in your X configuration file are ignored for TVs.
1871 To use your TV with X, there are several relevant X configuration options:
1873 o The Modes in the screen section of your X configuration file; you can use
1874 these to request any of the modes in the mode pool which the X driver
1875 created for this combination of TV standard and TV encoder. Examples
1876 include "640x480" and "800x600". If in doubt, use "nvidia-auto-select".
1878 o The "TVStandard" option should be added to your screen section; valid
1881 TVStandard Description
1882 ------------- --------------------------------------------------
1883 "PAL-B" used in Belgium, Denmark, Finland, Germany,
1884 Guinea, Hong Kong, India, Indonesia, Italy,
1885 Malaysia, The Netherlands, Norway, Portugal,
1886 Singapore, Spain, Sweden, and Switzerland
1887 "PAL-D" used in China and North Korea
1888 "PAL-G" used in Denmark, Finland, Germany, Italy,
1889 Malaysia, The Netherlands, Norway, Portugal,
1890 Spain, Sweden, and Switzerland
1891 "PAL-H" used in Belgium
1892 "PAL-I" used in Hong Kong and The United Kingdom
1893 "PAL-K1" used in Guinea
1894 "PAL-M" used in Brazil
1895 "PAL-N" used in France, Paraguay, and Uruguay
1896 "PAL-NC" used in Argentina
1897 "NTSC-J" used in Japan
1898 "NTSC-M" used in Canada, Chile, Colombia, Costa Rica,
1899 Ecuador, Haiti, Honduras, Mexico, Panama, Puerto
1900 Rico, South Korea, Taiwan, United States of
1901 America, and Venezuela
1902 "HD480i" 480 line interlaced
1903 "HD480p" 480 line progressive
1904 "HD720p" 720 line progressive
1905 "HD1080i" 1080 line interlaced
1906 "HD1080p" 1080 line progressive
1907 "HD576i" 576 line interlace
1908 "HD576p" 576 line progressive
1910 The line in your X config file should be something like:
1912 Option "TVStandard" "NTSC-M"
1914 If you do not specify a TVStandard, or you specify an invalid value, the
1915 default "NTSC-M" will be used. Note: if your country is not in the above
1916 list, select the country closest to your location.
1918 o The "UseDisplayDevice" option can be used if there are multiple display
1919 devices connected, and you want the connected TV to be used instead of
1920 the connected CRTs and/or DFPs. E.g.,
1922 Option "UseDisplayDevice" "TV"
1924 Using the "UseDisplayDevice" option, rather than the "ConnectedMonitor"
1925 option, is recommended.
1927 o The "TVOutFormat" option can be used to force the output format. Without
1928 this option, the driver autodetects the output format. Unfortunately, it
1929 does not always do this correctly. The output format can be forced with
1930 the "TVOutFormat" option; valid values are:
1932 TVOutFormat Description Supported TV
1934 ------------------- ------------------- -------------------
1935 "AUTOSELECT" The driver PAL, NTSC, HD
1939 "COMPOSITE" Force Composite PAL, NTSC
1941 "SVIDEO" Force S-Video PAL, NTSC
1943 "COMPONENT" Force Component HD
1946 "SCART" Force Scart output PAL, NTSC
1950 The line in your X config file should be something like:
1952 Option "TVOutFormat" "SVIDEO"
1955 o The "TVOverScan" option can be used to enable Overscan, when the TV
1956 encoder supports it. Valid values are decimal values in the range 1.0
1957 (which means overscan as much as possible: make the image as large as
1958 possible) and 0.0 (which means disable overscanning: make the image as
1959 small as possible). Overscanning is disabled (0.0) by default.
1961 The NVIDIA X driver may not restore the console correctly with XFree86
1962 versions older than 4.3 when the console is a TV. This is due to binary
1963 incompatibilities between XFree86 int10 modules. If you use a TV as your
1964 console it is recommended that you upgrade to XFree86 4.3 or later.
1966 ______________________________________________________________________________
1968 Chapter 14. Using the XRandR Extension
1969 ______________________________________________________________________________
1971 X.Org version X11R6.8.1 contains support for the rotation component of the
1972 XRandR extension, which allows screens to be rotated at 90 degree increments.
1974 The driver supports rotation with the extension when 'Option "RandRRotation"'
1975 is enabled in the X config file.
1977 Workstation RGB or CI overlay visuals will function at lower performance and
1978 the video overlay will not be available when RandRRotation is enabled.
1980 You can query the available rotations using the 'xrandr' command line
1981 interface to the RandR extension by running:
1985 You can set the rotation orientation of the screen by running any of:
1992 Rotation may also be set through the nvidia-settings configuration utility in
1993 the "Rotation Settings" panel.
1995 TwinView and rotation can be used together, but rotation affects the entire
1996 desktop. This means that the same rotation setting will apply to both display
1997 devices in a TwinView pair. Note also that the "TwinViewOrientation" option
1998 applies before rotation does. For example, if you have two screens
1999 side-by-side and you want to rotate them, you should set "TwinViewOrientation"
2000 to "Above" or "Below".
2002 ______________________________________________________________________________
2004 Chapter 15. Configuring a Notebook
2005 ______________________________________________________________________________
2008 15A. INSTALLATION AND CONFIGURATION
2010 Installation and configuration of the NVIDIA FreeBSD Driver Set on a notebook
2011 is the same as for any desktop environment, with a few additions, as described
2015 15B. POWER MANAGEMENT
2017 All notebook NVIDIA GPUs support power management, both S3 (also known as
2018 "Standby" or "Suspend to RAM") and S4 (also known as "Hibernate", "Suspend to
2019 Disk" or "SWSUSP"). Power management is system-specific and is dependent upon
2020 all the components in the system; some systems may be more problematic than
2023 Most recent notebook NVIDIA GPUs also support PowerMizer, which monitors
2024 application work load to adjust system parameters to deliver the optimal
2025 balance of performance and battery life. However, PowerMizer is only enabled
2026 by default on some notebooks. Please see the known issues below for more
2030 15C. HOTKEY SWITCHING OF DISPLAY DEVICES
2032 Mobile NVIDIA GPUs also have the capacity to react to a display change hotkey
2033 event, toggling between each of the connected display devices and each
2034 possible combination of the connected display devices (note that only 2
2035 display devices may be active at a time).
2037 Hotkey switching dynamically changes the TwinView configuration; a given
2038 hotkey event will indicate which display devices should be in use at that
2039 time, and all MetaModes currently configured on the X screen will be updated
2040 to use the new configuration of display devices.
2042 Another important aspect of hotkey functionality is that you can dynamically
2043 connect and remove display devices to/from your notebook and use the hotkey to
2044 activate and deactivate them without restarting X.
2046 Note that there are two approaches to implementing this hotkey support: ACPI
2049 Most recent notebooks use ACPI events to deliver hotkeys from the System BIOS
2050 to the graphics driver. This is the preferred method of delivering hotkey
2051 events, but is still a new feature under most UNIX platforms and may not
2052 always function correctly.
2054 The polling mechanism requires checking during the vertical blanking interval
2055 for a hotkey status change. It is an older mechanism for handling hotkeys, and
2056 is therefore not supported on all notebooks and is not tested by notebook
2057 manufacturers. It also does not always report the same combinations of display
2058 devices that are reported by ACPI hotkey events.
2060 The NVIDIA FreeBSD Driver will attempt to use ACPI hotkey events, if possible.
2061 In the case that ACPI hotkey event support is not available, the driver will
2062 revert back to trying hotkey polling. In the case that the notebook does not
2063 support hotkey polling, hotkeys will not work. Please see the known issues
2064 section below for more details.
2066 When switching away from X to a virtual terminal, the VGA console will always
2067 be restored to the display device on which it was present when X was started.
2068 Similarly, when switching back into X, the same display device configuration
2069 will be used as when you switched away, regardless of what display change
2070 hotkey activity occurred while the virtual terminal was active.
2075 All notebook NVIDIA GPUs support docking, however support may be limited by
2076 the OS or system. There are three types of notebook docking (hot, warm, and
2077 cold), which refer to the state of the system when the docking event occurs.
2078 hot refers to a powered on system with a live desktop, warm refers to a system
2079 that has entered a suspended power management state, and cold refers to a
2080 system that has been powered off. Only warm and cold docking are supported by
2086 All notebook NVIDIA GPUs support TwinView. TwinView on a notebook can be
2087 configured in the same way as on a desktop computer (refer to Chapter 10 );
2088 note that in a TwinView configuration using the notebook's internal flat panel
2089 and an external CRT, the CRT is the primary display device (specify its
2090 HorizSync and VertRefresh in the Monitor section of your X config file) and
2091 the flat panel is the secondary display device (specify its HorizSync and
2092 VertRefresh through the SecondMonitorHorizSync and SecondMonitorVertRefresh
2095 The "UseEdidFreqs" X config option is enabled by default, so normally you
2096 should not need to specify the "SecondMonitorHorizSync" and
2097 "SecondMonitorVertRefresh" options. See the description of the UseEdidFreqs
2098 option in Appendix F for details).
2101 15F. KNOWN NOTEBOOK ISSUES
2103 There are a few known issues associated with notebooks:
2105 o Display change hotkey switching is not available on all notebooks. In
2106 some cases, the ACPI infrastructure is not fully supported by the NVIDIA
2107 FreeBSD Driver. Work is ongoing to increase the robustness of NVIDIA's
2108 support in this area. Toshiba and Lenovo notebooks are known to be
2111 o ACPI Display change hotkey switching is not supported by X.Org X servers
2112 earlier than 1.2.0; see EnableACPIHotkeys in Appendix F for details.
2114 o In many cases, suspending and/or resuming will fail. As mentioned above,
2115 this functionality is very system-specific. There are still many cases
2116 that are problematic. Here are some tips that may help:
2118 o In some cases, hibernation can have bad interactions with the PCI
2119 Express bus clocks, which can lead to system hangs when entering
2120 hibernation. This issue is still being investigated, but a known
2121 workaround is to leave an OpenGL application running when
2125 o On some notebooks, PowerMizer is not enabled by default. This issue is
2126 being investigated, and there is no known workaround.
2128 o ACPI is not currently supported on FreeBSD As a result, ACPI hotkey
2129 events are not supported.
2131 o The video overlay only works on the first display device on which you
2132 started X. For example, if you start X on the internal LCD, run a video
2133 application that uses the video overlay (uses the "Video Overlay" adapter
2134 advertised through the XV extension), and then hotkey switch to add a
2135 second display device, the video will not appear on the second display
2136 device. To work around this, you can either configure the video
2137 application to use the "Video Blitter" adapter advertised through the XV
2138 extension (this is always available), or hotkey switch to the display
2139 device on which you want to use the video overlay *before* starting X.
2142 ______________________________________________________________________________
2144 Chapter 16. Programming Modes
2145 ______________________________________________________________________________
2147 The NVIDIA Accelerated FreeBSD Graphics Driver supports all standard VGA and
2148 VESA modes, as well as most user-written custom mode lines; double-scan modes
2149 are supported on all hardware. Interlaced modes are supported on all GeForce
2150 FX/Quadro FX and newer GPUs, and certain older GPUs; the X log file will
2151 contain a message "Interlaced video modes are supported on this GPU" if
2152 interlaced modes are supported.
2154 To request one or more standard modes for use in X, you can simply add a
2155 "Modes" line such as:
2157 Modes "1600x1200" "1024x768" "640x480"
2159 in the appropriate Display subsection of your X config file (see the
2160 XF86Config(5x) or xorg.conf(5x) man pages for details). Or, the
2161 nvidia-xconfig(1) utility can be used to request additional modes; for
2164 nvidia-xconfig --mode 1600x1200
2166 See the nvidia-xconfig(1) man page for details.
2169 16A. DEPTH, BITS PER PIXEL, AND PITCH
2171 While not directly a concern when programming modes, the bits used per pixel
2172 is an issue when considering the maximum programmable resolution; for this
2173 reason, it is worthwhile to address the confusion surrounding the terms
2174 "depth" and "bits per pixel". Depth is how many bits of data are stored per
2175 pixel. Supported depths are 8, 15, 16, and 24. Most video hardware, however,
2176 stores pixel data in sizes of 8, 16, or 32 bits; this is the amount of memory
2177 allocated per pixel. When you specify your depth, X selects the bits per pixel
2178 (bpp) size in which to store the data. Below is a table of what bpp is used
2179 for each possible depth:
2182 ---------------------------------- ----------------------------------
2188 Lastly, the "pitch" is how many bytes in the linear frame buffer there are
2189 between one pixel's data, and the data of the pixel immediately below. You can
2190 think of this as the horizontal resolution multiplied by the bytes per pixel
2191 (bits per pixel divided by 8). In practice, the pitch may be more than this
2192 product due to alignment constraints.
2195 16B. MAXIMUM RESOLUTIONS
2197 The NVIDIA Accelerated FreeBSD Graphics Driver and NVIDIA GPU-based graphics
2198 cards support resolutions up to 8192x8192 pixels for the GeForce 8 series and
2199 above, and up to 4096x4096 pixels for the GeForce 7 series and below, though
2200 the maximum resolution your system can support is also limited by the amount
2201 of video memory (see USEFUL FORMULAS for details) and the maximum supported
2202 resolution of your display device (monitor/flat panel/television). Also note
2203 that while use of a video overlay does not limit the maximum resolution or
2204 refresh rate, video memory bandwidth used by a programmed mode does affect the
2208 16C. USEFUL FORMULAS
2210 The maximum resolution is a function both of the amount of video memory and
2211 the bits per pixel you elect to use:
2213 HR * VR * (bpp/8) = Video Memory Used
2215 In other words, the amount of video memory used is equal to the horizontal
2216 resolution (HR) multiplied by the vertical resolution (VR) multiplied by the
2217 bytes per pixel (bits per pixel divided by eight). Technically, the video
2218 memory used is actually the pitch times the vertical resolution, and the pitch
2219 may be slightly greater than (HR * (bpp/8)) to accommodate the hardware
2220 requirement that the pitch be a multiple of some value.
2222 Note that this is just memory usage for the frame buffer; video memory is also
2223 used by other things, such as OpenGL and pixmap caching.
2225 Another important relationship is that between the resolution, the pixel clock
2226 (aka dot clock) and the vertical refresh rate:
2228 RR = PCLK / (HFL * VFL)
2230 In other words, the refresh rate (RR) is equal to the pixel clock (PCLK)
2231 divided by the total number of pixels: the horizontal frame length (HFL)
2232 multiplied by the vertical frame length (VFL) (note that these are the frame
2233 lengths, and not just the visible resolutions). As described in the XFree86
2234 Video Timings HOWTO, the above formula can be rewritten as:
2236 PCLK = RR * HFL * VFL
2238 Given a maximum pixel clock, you can adjust the RR, HFL and VFL as desired, as
2239 long as the product of the three is consistent. The pixel clock is reported in
2240 the log file. Your X log should contain a line like this:
2242 (--) NVIDIA(0): ViewSonic VPD150 (DFP-1): 165 MHz maximum pixel clock
2244 which indicates the maximum pixel clock for that display device.
2247 16D. HOW MODES ARE VALIDATED
2249 In traditional XFree86/X.Org mode validation, the X server takes as a starting
2250 point the X server's internal list of VESA standard modes, plus any modes
2251 specified with special ModeLines in the X configuration file's Monitor
2252 section. These modes are validated against criteria such as the valid
2253 HorizSync/VertRefresh frequency ranges for the user's monitor (as specified in
2254 the Monitor section of the X configuration file), as well as the maximum pixel
2257 Once the X server has determined the set of valid modes, it takes the list of
2258 user requested modes (i.e., the set of modes named in the "Modes" line in the
2259 Display subsection of the Screen section of X configuration file), and finds
2260 the "best" validated mode with the requested name.
2262 The NVIDIA X driver uses a variation on the above approach to perform mode
2263 validation. During X server initialization, the NVIDIA X driver builds a pool
2264 of valid modes for each display device. It gathers all possible modes from
2267 o The display device's EDID
2269 o The X server's built-in list
2271 o Any user-specified ModeLines in the X configuration file
2273 o The VESA standard modes
2275 For every possible mode, the mode is run through mode validation. The core of
2276 mode validation is still performed similarly to traditional XFree86/X.Org mode
2277 validation: the mode timings are checked against things such as the valid
2278 HorizSync and VertRefresh ranges and the maximum pixelclock. Note that each
2279 individual stage of mode validation can be independently controlled through
2280 the "ModeValidation" X configuration option.
2282 Note that when validating interlaced mode timings, VertRefresh specifies the
2283 field rate, rather than the frame rate. For example, the following modeline
2284 has a vertical refresh rate of 87 Hz:
2287 # 1024x768i @ 87Hz (industry standard)
2288 ModeLine "1024x768" 44.9 1024 1032 1208 1264 768 768 776 817 +hsync +vsync
2292 Invalid modes are discarded; valid modes are inserted into the mode pool. See
2293 MODE VALIDATION REPORTING for how to get more details on mode validation
2294 results for each considered mode.
2296 Valid modes are given a unique name that is guaranteed to be unique across the
2297 whole mode pool for this display device. This mode name is constructed
2298 approximately like this:
2300 <width>x<height>_<refreshrate>
2302 (e.g., "1600x1200_85")
2304 The name may also be prepended with another number to ensure the mode is
2305 unique; e.g., "1600x1200_85_0".
2307 As validated modes are inserted into the mode pool, duplicate modes are
2308 removed, and the mode pool is sorted, such that the "best" modes are at the
2309 beginning of the mode pool. The sorting is based roughly on:
2313 o Source (EDID-provided modes are prioritized higher than VESA-provided
2314 modes, which are prioritized higher than modes that were in the X
2315 server's built-in list)
2319 Once modes from all mode sources are validated and the mode pool is
2320 constructed, all modes with the same resolution are compared; the best mode
2321 with that resolution is added to the mode pool a second time, using just the
2322 resolution as its unique modename (e.g., "1600x1200"). In this way, when you
2323 request a mode using the traditional names (e.g., "1600x1200"), you still get
2324 what you got before (the 'best' 1600x1200 mode); the added benefit is that all
2325 modes in the mode pool can be addressed by a unique name.
2327 When verbose logging is enabled (see the FAQ section on increasing the amount
2328 of data printed in the X log file), the mode pool for each display device is
2329 printed to the X log file.
2331 After the mode pool is built for all display devices, the requested modes (as
2332 specified in the X configuration file), are looked up from the mode pool. Each
2333 requested mode that can be matched against a mode in the mode pool is then
2334 advertised to the X server and is available to the user through the X server's
2335 mode switching hotkeys (ctrl-alt-plus/minus) and the XRandR and XF86VidMode X
2338 If only one display device is in use by the X screen when the X server starts,
2339 all modes in the mode pool are implicitly made available to the X server. See
2340 the "IncludeImplicitMetaModes" X configuration option in Appendix F for
2344 16E. THE NVIDIA-AUTO-SELECT MODE
2346 You can request a special mode by name in the X config file, named
2347 "nvidia-auto-select". When the X driver builds the mode pool for a display
2348 device, it selects one of the modes as the "nvidia-auto-select" mode; a new
2349 entry is made in the mode pool, and "nvidia-auto-select" is used as the unique
2352 The "nvidia-auto-select" mode is intended to be a reasonable mode for the
2353 display device in question. For example, the "nvidia-auto-select" mode is
2354 normally the native resolution for flatpanels, as reported by the flatpanel's
2355 EDID, or one of the detailed timings from the EDID. The "nvidia-auto-select"
2356 mode is guaranteed to always be present, and to always be defined as something
2357 considered valid by the X driver for this display device.
2359 Note that the "nvidia-auto-select" mode is not necessarily the largest
2360 possible resolution, nor is it necessarily the mode with the highest refresh
2361 rate. Rather, the "nvidia-auto-select" mode is selected such that it is a
2362 reasonable default. The selection process is roughly:
2365 o If the EDID for the display device reported a preferred mode timing, and
2366 that mode timing is considered a valid mode, then that mode is used as
2367 the "nvidia-auto-select" mode. You can check if the EDID reported a
2368 preferred timing by starting X with logverbosity greater than or equal to
2369 5 (see the FAQ section on increasing the amount of data printed in the X
2370 log file), and looking at the EDID printout; if the EDID contains a line:
2372 Prefer first detailed timing : Yes
2374 Then the first mode listed under the "Detailed Timings" in the EDID will
2377 o If the EDID did not provide a preferred timing, the best detailed timing
2378 from the EDID is used as the "nvidia-auto-select" mode.
2380 o If the EDID did not provide any detailed timings (or there was no EDID at
2381 all), the best valid mode not larger than 1024x768 is used as the
2382 "nvidia-auto-select" mode. The 1024x768 limit is imposed here to restrict
2383 use of modes that may have been validated, but may be too large to be
2384 considered a reasonable default, such as 2048x1536.
2386 o If all else fails, the X driver will use a built-in 800 x 600 60Hz mode
2387 as the "nvidia-auto-select" mode.
2390 If no modes are requested in the X configuration file, or none of the
2391 requested modes can be found in the mode pool, then the X driver falls back to
2392 the "nvidia-auto-select" mode, so that X can always start. Appropriate warning
2393 messages will be printed to the X log file in these fallback scenarios.
2395 You can add the "nvidia-auto-select" mode to your X configuration file by
2398 nvidia-xconfig --mode nvidia-auto-select
2400 and restarting your X server.
2402 The X driver can generally do a much better job of selecting the
2403 "nvidia-auto-select" mode if the display device's EDID is available. This is
2404 one reason why the "IgnoreEDID" X configuration option has been deprecated,
2405 and that it is recommended to only use the "UseEDID" X configuration option
2406 sparingly. Note that, rather than globally disable all uses of the EDID with
2407 the "UseEDID" option, you can individually disable each particular use of the
2408 EDID using the "UseEDIDFreqs", "UseEDIDDpi", and/or the "NoEDIDModes" argument
2409 in the "ModeValidation" X configuration option.
2412 16F. MODE VALIDATION REPORTING
2414 When log verbosity is set to 6 or higher (see FAQ
2415 section on increasing the amount of data printed in the X log file), the X log
2416 will record every mode that is considered for each display device's mode pool,
2417 and report whether the mode passed or failed. For modes that were considered
2418 invalid, the log will report why the mode was considered invalid.
2421 16G. ENSURING IDENTICAL MODE TIMINGS
2423 Some functionality, such as Active Stereo with TwinView, requires control over
2424 exactly which mode timings are used. For explicit control over which mode
2425 timings are used on each display device, you can specify the ModeLine you want
2426 to use (using one of the ModeLine generators available), and using a unique
2427 name. For example, if you wanted to use 1024x768 at 120 Hz on each monitor in
2428 TwinView with active stereo, you might add something like this to the monitor
2429 section of your X configuration file:
2431 # 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz
2432 Modeline "1024x768_120" 139.05 1024 1104 1216 1408 768 769 772 823
2435 Then, in the Screen section of your X config file, specify a MetaMode like
2438 Option "MetaModes" "1024x768_120, 1024x768_120"
2442 16H. ADDITIONAL INFORMATION
2444 An XFree86 ModeLine generator, conforming to the GTF Standard is available at
2445 http://gtf.sourceforge.net/. Additional generators can be found by searching
2446 for "modeline" on freshmeat.net.
2448 ______________________________________________________________________________
2450 Chapter 17. Configuring Flipping and UBB
2451 ______________________________________________________________________________
2453 The NVIDIA Accelerated FreeBSD Graphics Driver supports Unified Back Buffer
2454 (UBB) and OpenGL Flipping. These features can provide performance gains in
2457 o Unified Back Buffer (UBB): UBB is available only on the Quadro family of
2458 GPUs (Quadro4 NVS excluded) and is enabled by default when there is
2459 sufficient video memory available. This can be disabled with the UBB X
2460 config option described in Appendix F. When UBB is enabled, all windows
2461 share the same back, stencil and depth buffers. When there are many
2462 windows, the back, stencil and depth usage will never exceed the size of
2463 that used by a full screen window. However, even for a single small
2464 window, the back, stencil, and depth video memory usage is that of a full
2465 screen window. In that case video memory may be used less efficiently
2466 than in the non-UBB case.
2468 o Flipping: When OpenGL flipping is enabled, OpenGL can perform buffer
2469 swaps by changing which buffer the DAC scans out rather than copying the
2470 back buffer contents to the front buffer; this is generally a much higher
2471 performance mechanism and allows tearless swapping during the vertical
2472 retrace (when __GL_SYNC_TO_VBLANK is set). The conditions under which
2473 OpenGL can flip are slightly complicated, but in general: on GeForce or
2474 newer hardware, OpenGL can flip when a single full screen unobscured
2475 OpenGL application is running, and __GL_SYNC_TO_VBLANK is enabled.
2476 Additionally, OpenGL can flip on Quadro hardware even when an OpenGL
2477 window is partially obscured or not full screen or __GL_SYNC_TO_VBLANK is
2481 ______________________________________________________________________________
2483 Appendix C. The Sysctl Interface
2484 ______________________________________________________________________________
2486 The sysctl interface allows you to obtain run-time information about the
2487 driver, any installed NVIDIA graphics cards and the AGP status. It also allows
2488 you to control low-level configuration options and/or overrides.
2490 The various pieces of information are held in a hierarchy under hw.nvidia and
2491 are accessible with the sysctl(8) command.
2493 NVIDIA sysctl Entries
2497 Prints the installed driver revision
2501 These OIDs provide information about NVIDIA device 'n':
2504 -------------------------------- --------------------------------
2505 model the device's product name
2506 irq the IRQ claimed by this device
2507 vbios the device's VBIOS revision
2508 type the bus type of this device
2511 hw.nvidia.agp.host-bridge.*
2512 hw.nvidia.agp.card.*
2514 These OIDs provide information about the AGP capabilities of the installed
2515 AGP graphics card and host-bridge respectively. These values are most
2516 likely to be correct after system boot and before the X server is started
2517 (and the AGP subsystem intialized).
2520 -------------- ---------------------------------------------------
2521 rates the AGP rates supported by this device
2522 fw if the device suppoprts AGP fast-writes
2523 sba if the device supports AGP side-band-addressing
2524 registers the device's AGP registers, status:command
2527 hw.nvidia.agp.status.*
2529 Prints AGP status information based on the AGP command registers of the
2530 host-bridge and of the AGP card.
2533 -------------- ---------------------------------------------------
2534 status if AGP is enabled or disabled
2535 driver which driver is being used
2536 rate the programmed AGP rate
2537 fw if fast-writes are enabled or disabled
2538 sba if side-band-addressing is enabled or disabled
2541 hw.nvidia.registry.*
2543 Low-level kernel module configuration options. Changing these is typically
2544 not necessary and potentially dangerous. If you do need to change any of
2545 these options, you will need to do so BEFORE you start the X server.
2548 -------------- ---------------------------------------------------
2549 status if AGP is enabled or disabled
2550 driver which driver is being used
2551 rate the programmed AGP rate
2552 fw if fast-writes are enabled or disabled
2553 sba if side-band-addressing is enabled or disabled
2557 ______________________________________________________________________________
2559 Appendix D. Configuring Low-level Parameters
2560 ______________________________________________________________________________
2562 The NVIDIA resource manager recognizes several low-level configuration
2563 parameters that can be set using the sysctl driver interface BEFORE the X
2564 server is started. Normally you should not need to modify any of these
2565 parameters, but it is sometimes necessary or desirable to do so.
2567 To view the current settings of these parameters, you need to issue this
2568 sysctl command ('nvidia.ko' needs to be loaded):
2570 % sysctl -a hw.nvidia.registry
2572 To change any of the parameters, you need to pass the complete name of the OID
2573 followed by '=' and the new value, e.g.:
2575 % sysctl hw.nvidia.registry.EnableVia4x=1
2577 It is possible to automate setting these paramaters by adding them to the
2578 '/etc/sysctl.conf' file. See `man 5 sysctl.conf` for details.
2580 The following parameters are recognized by 'nvidia.ko':
2582 Resource Manager Parameters
2584 VideoMemoryTypeOverride
2586 We normally detect memory type on TNT cards by scanning the embedded BIOS.
2587 Unfortunately, we've seen some cases where a TNT card has been flashed
2588 with the wrong bios. For example, an SDRAM based TNT has been flashed with
2589 an SGRAM bios, and therefore claims to be an SGRAM TNT. We've therefore
2590 provided an override here. Make sure to set the value toe the type of
2591 memory used on your card.
2594 -------------------------------- --------------------------------
2598 Note that we can only do so much here. There are border cases where even
2599 this fails. For example, if 2 TNT cards are in the same system, one SGRAM,
2602 This option is disabled by default, see below for information on how to
2607 We've had problems with some Via chipsets in 4x mode, we need force them
2608 back down to 2x mode. If you'd like to experiment with retaining 4x mode,
2609 you may try setting this value to 1 If that hangs the system, you're stuck
2610 with 2x mode; there's nothing we can do about it.
2613 -------------- ---------------------------------------------------
2614 0 disable AGP 4x on Via chipsets (default)
2615 1 enable AGP 4x on Via chipsets
2620 Some ALi chipsets (ALi1541, ALi1647) are known to cause severe system
2621 stability problems with AGP enabled. To avoid lockups, we disable AGP on
2622 systems with these chipsets by default. It appears that updating the
2623 system BIOS and using recent versions of the kernel AGP Gart driver can
2624 make such systems much more stable. If you own a system with one of the
2625 aforementioned chipsets and had it working reasonably well previously, or
2626 if you want to experiment with BIOS and AGPGART revisions, you can
2627 re-enable AGP support by setting this option to 1.
2630 -------------- ---------------------------------------------------
2631 0 disable AGP on Ali1541 and ALi1647 (default)
2632 1 enable AGP on Ali1541 and ALi1647
2637 This options controls which AGP GART driver is used when no explicit
2638 request is made to change the default (X server).
2641 -------------- ---------------------------------------------------
2642 0 disable AGP support
2643 1 use the NVIDIA builtin driver (if possible)
2644 2 use the kernel's AGPGART driver (if possible)
2645 3 use any available driver (try 2, then 1)
2647 Note that the NVIDIA internal AGP GART driver will not be used if AGPGART
2648 was either statically linked into your kernel or built as a kernel module
2649 and loaded before the NVIDIA kernel module.
2653 Normally, the driver will compare speed modes of the chipset and the card,
2654 picking the highest common rate. This key forces a maximum limit, to limit
2655 the driver to lower speeds. The driver will not attempt a speed beyond
2656 what the chipset and card claim they are capable of.
2658 Make sure you really know what you're doing before you enable this
2659 override. By default, AGP drivers will enable the fastest AGP rate your
2660 card and motherboard chipset are capable of. Then, in some cases, our
2661 driver will force this rate down to work around bugs in both our chipsets,
2662 and motherboard chipsets. Using this variable will override our bug fixes.
2663 This may be desirable in some cases, but not most. THIS IS COMPLETELY
2666 This option expects a bitmask (7 = 1|2|3|4, 3=1|2, etc.)
2668 This option is disabled by default, see below for information on how to
2673 For stability reasons, the driver will not Side Band Addressing even if
2674 both the host chipset and the AGP card support it. You may override this
2675 behaviour with the following registry key. THIS IS COMPLETELY UNSUPPORTED!
2679 -------------- ---------------------------------------------------
2680 0 disable Side Band Addressing (default on x86, see
2682 1 enable Side Band Addressing (if supported)
2687 Similar to Side Band Addressing, Fast Writes are disabled by default. If
2688 you wish to enable them on systems that support them, you can do so with
2689 this registry key. Note that this may render your system unstable with
2690 many AGP chipsets. THIS IS COMPLETELY UNSUPPORTED!
2693 -------------------------------- --------------------------------
2694 0 disable Fast Writes (default)
2695 1 enable Fast Writes
2699 ______________________________________________________________________________
2701 Chapter 18. Using the X Composite Extension
2702 ______________________________________________________________________________
2704 X.Org X servers, beginning with X11R6.8.0, contain experimental support for a
2705 new X protocol extension called Composite. This extension allows windows to be
2706 drawn into pixmaps instead of directly onto the screen. In conjunction with
2707 the Damage and Render extensions, this allows a program called a composite
2708 manager to blend windows together to draw the screen.
2710 Performance will be degraded significantly if the "RenderAccel" option is
2711 disabled in xorg.conf. See Appendix F for more details.
2713 When the NVIDIA X driver is used with an X.Org X server X11R6.9.0 or newer and
2714 the Composite extension is enabled, NVIDIA's OpenGL implementation interacts
2715 properly with the Damage and Composite X extensions. This means that OpenGL
2716 rendering is drawn into offscreen pixmaps and the X server is notified of the
2717 Damage event when OpenGL renders to the pixmap. This allows OpenGL
2718 applications to behave properly in a composited X desktop.
2720 If the Composite extension is enabled on an X server older than X11R6.9.0,
2721 then GLX will be disabled. You can force GLX on while Composite is enabled on
2722 pre-X11R6.9.0 X servers with the "AllowGLXWithComposite" X configuration
2723 option. However, GLX will not render correctly in this environment. Upgrading
2724 your X server to X11R6.9.0 or newer is recommended.
2726 You can enable the Composite X extension by running 'nvidia-xconfig
2727 --composite'. Composite can be disabled with 'nvidia-xconfig --no-composite'.
2728 See the nvidia-xconfig(1) man page for details.
2730 If you are using Composite with GLX, it is recommended that you also enable
2731 the "DamageEvents" X option for enhanced performance. If you are using an
2732 OpenGL-based composite manager, you may also need the "DisableGLXRootClipping"
2733 option to obtain proper output.
2735 The Composite extension also causes problems with other driver components:
2737 o In X servers prior to X.Org 7.1, Xv cannot draw into pixmaps that have
2738 been redirected offscreen and will draw directly onto the screen instead.
2739 For some programs you can work around this issue by using an alternative
2740 video driver. For example, "mplayer -vo x11" will work correctly, as will
2741 "xine -V xshm". If you must use Xv with an older server, you can also
2742 disable the compositing manager and re-enable it when you are finished.
2744 On X.Org 7.1 and higher, the driver will properly redirect video into
2745 offscreen pixmaps. Note that the Xv adaptors will ignore the
2746 sync-to-vblank option when drawing into a redirected window.
2748 o Workstation overlays, stereo visuals, and the unified back buffer (UBB)
2749 are incompatible with Composite. These features will be automatically
2750 disabled when Composite is detected.
2753 This NVIDIA FreeBSD supports OpenGL rendering to 32-bit ARGB windows on X.Org
2754 7.2 and higher or when the "AddARGBGLXVisuals" X config file option is
2755 enabled. If you are an application developer, you can use these new visuals in
2756 conjunction with a composite manager to create translucent OpenGL
2760 GLX_RENDER_TYPE, GLX_RGBA_BIT,
2761 GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT,
2766 GLX_DOUBLEBUFFER, True,
2769 GLXFBConfig *fbconfigs, fbconfig;
2770 int numfbconfigs, render_event_base, render_error_base;
2771 XVisualInfo *visinfo;
2772 XRenderPictFormat *pictFormat;
2774 /* Make sure we have the RENDER extension */
2775 if(!XRenderQueryExtension(dpy, &render_event_base, &render_error_base)) {
2776 fprintf(stderr, "No RENDER extension found\n");
2780 /* Get the list of FBConfigs that match our criteria */
2781 fbconfigs = glXChooseFBConfig(dpy, scrnum, attrib, &numfbconfigs);
2787 /* Find an FBConfig with a visual that has a RENDER picture format that
2789 for (i = 0; i < numfbconfigs; i++) {
2790 visinfo = glXGetVisualFromFBConfig(dpy, fbconfigs[i]);
2791 if (!visinfo) continue;
2792 pictFormat = XRenderFindVisualFormat(dpy, visinfo->visual);
2793 if (!pictFormat) continue;
2795 if(pictFormat->direct.alphaMask > 0) {
2796 fbconfig = fbconfigs[i];
2803 if (i == numfbconfigs) {
2804 /* None of the FBConfigs have alpha. Use a normal (opaque)
2805 * FBConfig instead */
2806 fbconfig = fbconfigs[0];
2807 visinfo = glXGetVisualFromFBConfig(dpy, fbconfig);
2808 pictFormat = XRenderFindVisualFormat(dpy, visinfo->visual);
2814 When rendering to a 32-bit window, keep in mind that the X RENDER extension,
2815 used by most composite managers, expects "premultiplied alpha" colors. This
2816 means that if your color has components (r,g,b) and alpha value a, then you
2817 must render (a*r, a*g, a*b, a) into the target window.
2819 More information about Composite can be found at
2820 http://freedesktop.org/Software/CompositeExt
2822 ______________________________________________________________________________
2824 Chapter 19. Using the nvidia-settings Utility
2825 ______________________________________________________________________________
2827 A graphical configuration utility, 'nvidia-settings', is included with the
2828 NVIDIA FreeBSD graphics driver. After installing the driver and starting X,
2829 you can run this configuration utility by running:
2833 in a terminal window.
2835 Detailed information about the configuration options available are documented
2836 in the help window in the utility.
2838 For more information, see the nvidia-settings man page or the user guide
2840 ftp://download.nvidia.com/XFree86/Linux-x86/nvidia-settings-user-guide.txt
2842 The source code to nvidia-settings is released as GPL and is available here:
2843 ftp://download.nvidia.com/XFree86/nvidia-settings/
2845 If you have trouble running the nvidia-settings binary shipped with the NVIDIA
2846 FreeBSD Graphics Driver, refer to the nvidia-settings entry in Chapter 6.
2848 ______________________________________________________________________________
2850 Chapter 20. Configuring SLI and Multi-GPU FrameRendering
2851 ______________________________________________________________________________
2853 The NVIDIA FreeBSD driver contains support for NVIDIA SLI FrameRendering and
2854 NVIDIA Multi-GPU FrameRendering. Both of these technologies allow an OpenGL
2855 application to take advantage of multiple GPUs to improve visual performance.
2857 The distinction between SLI and Multi-GPU is straightforward. SLI is used to
2858 leverage the processing power of GPUs across two or more graphics cards, while
2859 Multi-GPU is used to leverage the processing power of two GPUs colocated on
2860 the same graphics card. If you want to link together separate graphics cards,
2861 you should use the "SLI" X config option. Likewise, if you want to link
2862 together GPUs on the same graphics card, you should use the "MultiGPU" X
2863 config option. If you have two cards, each with two GPUs, and you wish to link
2864 them all together, you should use the "SLI" option.
2866 In FreeBSD, with two GPUs SLI and Multi-GPU can both operate in one of three
2867 modes: Alternate Frame Rendering (AFR), Split Frame Rendering (SFR), and
2868 Antialiasing (AA). When AFR mode is active, one GPU draws the next frame while
2869 the other one works on the frame after that. In SFR mode, each frame is split
2870 horizontally into two pieces, with one GPU rendering each piece. The split
2871 line is adjusted to balance the load between the two GPUs. AA mode splits
2872 antialiasing work between the two GPUs. Both GPUs work on the same scene and
2873 the result is blended together to produce the final frame. This mode is useful
2874 for applications that spend most of their time processing with the CPU and
2875 cannot benefit from AFR.
2877 With four GPUs, the same options are applicable. AFR mode cycles through all
2878 four GPUs, each GPU rendering a frame in turn. SFR mode splits the frame
2879 horizontally into four pieces. AA mode splits the work between the four GPUs,
2880 allowing antialiasing up to 64x. With four GPUs SLI can also operate in an
2881 additional mode, Alternate Frame Rendering of Antialiasing. (AFR of AA). With
2882 AFR of AA, pairs of GPUs render alternate frames, each GPU in a pair doing
2883 half of the antialiasing work. Note that these scenarios apply whether you
2884 have four separate cards or you have two cards, each with two GPUs.
2886 Multi-GPU is enabled by setting the "MultiGPU" option in the X configuration
2887 file; see Appendix F for details about the "MultiGPU" option.
2889 The nvidia-xconfig utility can be used to set the "MultiGPU" option, rather
2890 than modifying the X configuration file by hand. For example:
2892 % nvidia-xconfig --multigpu=on
2895 SLI is enabled by setting the "SLI" option in the X configuration file; see
2896 Appendix F for details about the SLI option.
2898 The nvidia-xconfig utility can be used to set the SLI option, rather than
2899 modifying the X configuration file by hand. For example:
2901 % nvidia-xconfig --sli=on
2905 20A. HARDWARE REQUIREMENTS
2907 SLI functionality requires:
2909 o Identical PCI-Express graphics cards
2911 o A supported motherboard
2913 o In most cases, a video bridge connecting the two graphics cards
2915 For the latest in supported SLI and Multi-GPU configurations, including SLI-
2916 and Multi-GPU capable GPUs and SLI-capable motherboards, see
2917 http://www.slizone.com.
2920 20B. OTHER NOTES AND REQUIREMENTS
2922 The following other requirements apply to SLI and Multi-GPU:
2924 o Mobile GPUs are NOT supported
2926 o SLI on Quadro-based graphics cards always requires a video bridge
2928 o TwinView is also not supported with SLI or Multi-GPU. Only one display
2929 can be used when SLI or Multi-GPU is enabled.
2931 o If X is configured to use multiple screens and screen 0 has SLI or
2932 Multi-GPU enabled, the other screens will be disabled. Note that if SLI
2933 or Multi-GPU is enabled, the GPUs used by that configuration will be
2934 unavailable for single GPU rendering.
2938 FREQUENTLY ASKED SLI AND MULTI-GPU QUESTIONS
2940 Q. Why is glxgears slower when SLI or Multi-GPU is enabled?
2942 A. When SLI or Multi-GPU is enabled, the NVIDIA driver must coordinate the
2943 operations of all GPUs when each new frame is swapped (made visible). For
2944 most applications, this GPU synchronization overhead is negligible.
2945 However, because glxgears renders so many frames per second, the GPU
2946 synchronization overhead consumes a significant portion of the total time,
2947 and the framerate is reduced.
2950 Q. Why is Doom 3 slower when SLI or Multi-GPU is enabled?
2952 A. The NVIDIA Accelerated FreeBSD Graphics Driver does not automatically
2953 detect the optimal SLI or Multi-GPU settings for games such as Doom 3 and
2954 Quake 4. To work around this issue, the environment variable __GL_DOOM3 can
2955 be set to tell OpenGL that Doom 3's optimal settings should be used. In
2956 Bash, this can be done in the same command that launches Doom 3 so the
2957 environment variable does not remain set for other OpenGL applications
2958 started in the same session:
2960 % __GL_DOOM3=1 doom3
2962 Doom 3's startup script can also be modified to set this environment
2966 # Needed to make symlinks/shortcuts work.
2967 # the binaries must run with correct working directory
2968 cd "/usr/local/games/doom3/"
2969 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
2971 exec ./doom.x86 "$@"
2973 This environment variable is temporary and will be removed in the future.
2976 ______________________________________________________________________________
2978 Chapter 21. Configuring Frame Lock and Genlock
2979 ______________________________________________________________________________
2981 NOTE: Frame Lock and Genlock features are supported only on specific hardware,
2984 Visual computing applications that involve multiple displays, or even multiple
2985 windows within a display, can require special signal processing and
2986 application controls in order to function properly. For example, in order to
2987 produce quality video recording of animated graphics, the graphics display
2988 must be synchronized with the video camera. As another example, applications
2989 presented on multiple displays must be synchronized in order to complete the
2990 illusion of a larger, virtual canvas.
2992 This synchronization is enabled through the frame lock and genlock
2993 capabilities of the NVIDIA driver. This section describes the setup and use of
2994 frame lock and genlock.
2997 21A. DEFINITION OF TERMS
2999 GENLOCK: Genlock refers to the process of synchronizing the pixel scanning of
3000 one or more displays to an external synchronization source. NVIDIA Genlock
3001 requires the external signal to be either TTL or composite, such as used for
3002 NTSC, PAL, or HDTV. It should be noted that the NVIDIA Genlock implementation
3003 is guaranteed only to be frame-synchronized, and not necessarily
3006 FRAME LOCK: Frame Lock involves the use of hardware to synchronize the frames
3007 on each display in a connected system. When graphics and video are displayed
3008 across multiple monitors, frame locked systems help maintain image continuity
3009 to create a virtual canvas. Frame lock is especially critical for stereo
3010 viewing, where the left and right fields must be in sync across all displays.
3012 In short, to enable genlock means to sync to an external signal. To enable
3013 frame lock means to sync 2 or more display devices to a signal generated
3014 internally by the hardware, and to use both means to sync 2 or more display
3015 devices to an external signal.
3017 SWAP SYNC: Swap sync refers to the synchronization of buffer swaps of multiple
3018 application windows. By means of swap sync, applications running on multiple
3019 systems can synchronize the application buffer swaps between all the systems.
3020 In order to work across multiple systems, swap sync requires that the systems
3023 G-SYNC DEVICE: A G-Sync Device refers to devices capable of Frame
3024 lock/Genlock. This can be a graphics card (Quadro FX 3000G) or a stand alone
3025 device (Quadro FX G-Sync). See "Supported Hardware" below.
3028 21B. SUPPORTED HARDWARE
3030 Frame lock and genlock are supported for the following hardware:
3033 ----------------------------------------------------------------------
3035 Quadro FX G-Sync, used in conjunction with a Quadro FX 4400, Quadro FX
3036 4500, or Quadro FX 5500
3042 Before you begin, you should check that your hardware has been properly
3043 installed. If you are using the Quadro FX 3000G, the genlock/frame lock signal
3044 processing hardware is located on the dual-slot card itself, and after
3045 installing the card, no additional setup is necessary.
3047 If you are using the Quadro FX G-Sync card in conjunction with a graphics
3048 card, the following additional setup steps are required. These steps must be
3049 performed when the system is off.
3051 1. On the Quadro FX G-Sync card, locate the fourteen-pin connector labeled
3052 "primary". If the associated ribbon cable is not already joined to this
3053 connector, do so now. If you plan to use frame lock or genlock in
3054 conjunction with SLI FrameRendering or Multi-GPU FrameRendering (see
3055 Chapter 20) or other multi-GPU configurations, you should connect the
3056 fourteen-pin connector labeled "secondary" to the second GPU. A section
3057 at the end of this appendix describes restrictions on such setups.
3059 2. Install the Quadro FX G-Sync card in any available slot. Note that the
3060 slot itself is only used for support, so even a known "bad" slot is
3061 acceptable. The slot must be close enough to the graphics card that the
3062 ribbon cable can reach.
3064 3. Connect the other end of the ribbon cable to the fourteen-pin connector
3065 on the graphics card.
3067 You may now boot the system and begin the software setup of genlock and/or
3068 frame lock. These instructions assume that you have already successfully
3069 installed the NVIDIA Accelerated FreeBSD Driver Set. If you have not done so,
3073 21D. CONFIGURATION WITH NVIDIA-SETTINGS GUI
3075 Frame lock and genlock are configured through the nvidia-settings utility. See
3076 the 'nvidia-settings(1)' man page, and the nvidia-settings online help (click
3077 the "Help" button in the lower right corner of the interface for per-page help
3080 From the nvidia-settings frame lock panel, you may control the addition of
3081 G-Sync (and display) devices to the frame lock/genlock group, monitor the
3082 status of that group, and enable/disable frame lock and genlock.
3084 After the system has booted and X Windows has been started, run
3089 You may wish to start this utility before continuing, as we refer to it
3090 frequently in the subsequent discussion.
3092 The setup of genlock and frame lock are described separately. We then describe
3093 the use of genlock and frame lock together.
3098 After the system has been booted, connect the external signal to the house
3099 sync connector (the BNC connector) on either the graphics card or the G-Sync
3100 card. There is a status LED next to the connector. A solid red LED indicates
3101 that the hardware cannot detect the timing signal. A green LED indicates that
3102 the hardware is detecting a timing signal. An occasional red flash is okay.
3103 The G-Sync device (graphics card or G-Sync card) will need to be configured
3104 correctly for the signal to be detected.
3106 In the frame lock panel of the nvidia-settings interface, add the X Server
3107 that contains the display and G-Sync devices that you would like to sync to
3108 this external source by clicking the "Add Devices..." button. An X Server is
3109 typically specified in the format "system:m", e.g.:
3111 mycomputer.domain.com:0
3117 After adding an X Server, rows will appear in the "G-Sync Devices" section on
3118 the frame lock panel that displays relevant status information about the
3119 G-Sync devices, GPUs attached to those G-Sync devices and the display devices
3120 driven by those GPUs. In particular, the G-Sync rows will display the server
3121 name and G-Sync device number along with "Receiving" LED, "Rate", "House" LED,
3122 "Port0"/"Port1" Images, and "Delay" information. The GPU rows will display the
3123 GPU product name information along with the GPU ID for the server. The Display
3124 Device rows will show the display device name and device type along with
3125 server/client checkboxes, refresh rate, "Timing" LED and "Stereo" LED.
3127 Once the G-Sync and display devices have been added to the frame lock/genlock
3128 group, a Server display device will need to be selected. This is done by
3129 selecting the "Server" checkbox of the desired display device.
3131 If you are using a G-Sync card, you must also click the "Use House Sync if
3132 Present" checkbox. To enable synchronization of this G-Sync device to the
3133 external source, click the "Enable Frame Lock" button. The display device(s)
3134 may take a moment to stabilize. If it does not stabilize, you may have
3135 selected a synchronization signal that the system cannot support. You should
3136 disable synchronization by clicking the "Disable Frame Lock" button and check
3137 the external sync signal.
3139 Modifications to genlock settings (e.g., "Use House Sync if Present", "Add
3140 Devices...") must be done while synchronization is disabled.
3143 21F. FRAME LOCK SETUP
3145 Frame Lock is supported across an arbitrary number of Quadro FX 3000 or Quadro
3146 FX G-Sync systems, although mixing the two in the same frame lock group is not
3147 supported. Additionally, each system to be included in the frame lock group
3148 must be configured with identical mode timings. See Chapter 16 for information
3151 Connect the systems through their RJ45 ports using standard CAT5 patch cables.
3152 These ports are located on the frame lock card itself (either the Quadro FX
3153 3000 or the Quadro FX G-Sync card). DO NOT CONNECT A FRAME LOCK PORT TO AN
3154 ETHERNET CARD OR HUB. DOING SO MAY PERMANENTLY DAMAGE THE HARDWARE. The
3155 connections should be made in a daisy-chain fashion: each card has two RJ45
3156 ports, call them 1 and 2. Connect port 1 of system A to port 2 of system B,
3157 connect port 1 of system B to port 2 of system C, etc. Note that you will
3158 always have two empty ports in your frame lock group.
3160 The ports self-configure as inputs or outputs once frame lock is enabled. Each
3161 port has a yellow and a green LED that reflect this state. A flashing yellow
3162 LED indicates an output and a flashing green LED indicates an input. A solid
3163 green LED indicates that the port has not yet configured.
3165 In the frame lock panel of the nvidia-settings interface, add the X server
3166 that contains the display devices that you would like to include in the frame
3167 lock group by clicking the "Add Devices..." button (see the description for
3168 adding display devices in the previous section on GENLOCK SETUP. Like the
3169 genlock status indicators, the "Port0" and "Port1" columns in the table on the
3170 frame lock panel contain indicators whose states mirror the states of the
3171 physical LEDs on the RJ45 ports. Thus, you may monitor the status of these
3172 ports from the software interface.
3174 Any X Server can be added to the frame lock group, provided that
3176 1. The system supporting the X Server is configured to support frame lock
3177 and is connected via RJ45 cable to the other systems in the frame lock
3180 2. The system driving nvidia-settings can locate and has display privileges
3181 on the X server that is to be included for frame lock.
3183 A system can gain display privileges on a remote system by executing
3187 on the remote system. See the xhost(1) man page for details. Typically, frame
3188 lock is controlled through one of the systems that will be included in the
3189 frame lock group. While this is not a requirement, note that nvidia-settings
3190 will only display the frame lock panel when running on an X server that
3191 supports frame lock.
3193 To enable synchronization on these display devices, click the "Enable Frame
3194 Lock" button. The screens may take a moment to stabilize. If they do not
3195 stabilize, you may have selected mode timings that one or more of the systems
3196 cannot support. In this case you should disable synchronization by clicking
3197 the "Disable Frame Lock" button and refer to Chapter 16 for information on
3200 Modifications to frame lock settings (e.g. "Add/Remove Devices...") must be
3201 done while synchronization is disabled.
3204 21G. FRAME LOCK + GENLOCK
3206 The use of frame lock and genlock together is a simple extension of the above
3207 instructions for using them separately. You should first follow the
3208 instructions for Frame Lock Setup, and then to one of the systems that will be
3209 included in the frame lock group, attach an external sync source. In order to
3210 sync the frame lock group to this single external source, you must select a
3211 display device driven by the GPU connected to the G-Sync card (through the
3212 primary connector) that is connected to the external source to be the signal
3213 server for the group. This is done by selecting the checkbox labeled "Server"
3214 of the tree on the frame lock panel in nvidia-settings. If you are using a
3215 G-Sync based frame lock group, you must also select the "Use House Sync if
3216 Present" checkbox. Enable synchronization by clicking the "Enable Frame Lock"
3217 button. As with other frame lock/genlock controls, you must select the signal
3218 server while synchronization is disabled.
3221 21H. CONFIGURATION WITH NVIDIA-SETTINGS COMMAND LINE
3223 Frame Lock may also be configured through the nvidia-settings command line.
3224 This method of configuring Frame Lock may be useful in a scripted environment
3225 to automate the setup process. (Note that the examples listed below depend on
3226 the actual hardware configuration and as such may not work as-is.)
3228 To properly configure Frame Lock, the following steps should be completed:
3230 1. Make sure Frame Lock Sync is disabled on all GPUs.
3232 2. Make sure all display devices that are to be frame locked have the same
3235 3. Configure which (display/GPU) device should be the master.
3237 4. Configure house sync (if applicable).
3239 5. Configure the slave display devices.
3241 6. Enable frame lock sync on the master GPU.
3243 7. Enable frame lock sync on the slave GPUs.
3245 8. Toggle the test signal on the master GPU (for testing the hardware
3249 For a full list of the nvidia-settings Frame Lock attributes, please see the
3250 'nvidia-settings(1)' man page. Examples:
3252 1. 1 System, 1 Frame Lock board, 1 GPU, and 1 display device syncing to the
3255 # - Make sure frame lock sync is disabled
3256 nvidia-settings -a [gpu:0]/FrameLockEnable=0
3257 nvidia-settings -q [gpu:0]/FrameLockEnable
3259 # - Query the enabled displays on the gpu
3260 nvidia-settings -q [gpu:0]/EnabledDisplays
3262 # - Check that the refresh rate is the one we want
3263 nvidia-settings -q [gpu:0]/RefreshRate
3265 # - Set the master display device to CRT-0. The desired display
3266 # device(s) to be set are passed in as a hexadecimal number
3267 # in which specific bits denote which display devices to set.
3270 # 0x00000001 - CRT-0
3271 # 0x00000002 - CRT-1
3272 # 0x00000003 - CRT-0 and CRT-1
3277 # 0x00020000 - DFP-1
3279 # 0x00010101 - CRT-0, TV-0 and DFP-0
3281 # 0x000000FF - All CRTs
3282 # 0x0000FF00 - All TVs
3283 # 0x00FF0000 - All DFPs
3285 # Note that the following command:
3287 # nvidia-settings -q [gpu:0]/EnabledDisplays
3289 # will list the available displays on the given GPU.
3291 nvidia-settings -a [gpu:0]/FrameLockMaster=0x00000001
3292 nvidia-settings -q [gpu:0]/FrameLockMaster
3294 # - Enable use of house sync signal
3295 nvidia-settings -a [framelock:0]/FrameLockUseHouseSync=1
3297 # - Configure the house sync signal video mode
3298 nvidia-settings -a [framelock:0]/FrameLockVideoMode=0
3300 # - Set the slave display device to none (to avoid
3301 # having unwanted display devices locked to the
3303 nvidia-settings -a [gpu:0]/FrameLockSlaves=0x00000000
3304 nvidia-settings -q [gpu:0]/FrameLockSlaves
3306 # - Enable framelocking
3307 nvidia-settings -a [gpu:0]/FrameLockEnable=1
3309 # - Toggle the test signal
3310 nvidia-settings -a [gpu:0]/FrameLockTestSignal=1
3311 nvidia-settings -a [gpu:0]/FrameLockTestSignal=0
3314 2. 2 Systems, each with 2 GPUs, 1 Frame Lock board and 1 display device per
3315 GPU syncing from the first system's first display device:
3317 # - Make sure frame lock sync is disabled
3318 nvidia-settings -a myserver:0[gpu:0]/FrameLockEnable=0
3319 nvidia-settings -a myserver:0[gpu:1]/FrameLockEnable=0
3320 nvidia-settings -a myslave1:0[gpu:0]/FrameLockEnable=0
3321 nvidia-settings -a myslave1:0[gpu:1]/FrameLockEnable=0
3323 # - Query the enabled displays on the GPUs
3324 nvidia-settings -q myserver:0[gpu:0]/EnabledDisplays
3325 nvidia-settings -q myserver:0[gpu:1]/EnabledDisplays
3326 nvidia-settings -q myslave1:0[gpu:0]/EnabledDisplays
3327 nvidia-settings -q myslave1:0[gpu:1]/EnabledDisplays
3329 # - Check the refresh rate is the same for all displays
3330 nvidia-settings -q myserver:0[gpu:0]/RefreshRate
3331 nvidia-settings -q myserver:0[gpu:1]/RefreshRate
3332 nvidia-settings -q myslave1:0[gpu:0]/RefreshRate
3333 nvidia-settings -q myslave1:0[gpu:1]/RefreshRate
3335 # - Make sure the display device we want as master is masterable
3336 nvidia-settings -q myserver:0[gpu:0]/FrameLockMasterable
3338 # - Set the master display device (CRT-0)
3339 nvidia-settings -a myserver:0[gpu:0]/FrameLockMaster=0x00000001
3341 # - Disable the house sync signal on the master device
3342 nvidia-settings -a myserver:0[framelock:0]/FrameLockUseHouseSync=0
3344 # - Set the slave display devices
3345 nvidia-settings -a myserver:0[gpu:1]/FrameLockSlaves=0x00000001
3346 nvidia-settings -a myslave1:0[gpu:0]/FrameLockSlaves=0x00000001
3347 nvidia-settings -a myslave1:0[gpu:1]/FrameLockSlaves=0x00000001
3349 # - Enable framelocking on server
3350 nvidia-settings -a myserver:0[gpu:0]/FrameLockEnable=1
3352 # - Enable framelocking on slave devices
3353 nvidia-settings -a myserver:0[gpu:1]/FrameLockEnable=1
3354 nvidia-settings -a myslave1:0[gpu:0]/FrameLockEnable=1
3355 nvidia-settings -a myslave1:0[gpu:1]/FrameLockEnable=1
3357 # - Toggle the test signal
3358 nvidia-settings -a myserver:0[gpu:0]/FrameLockTestSignal=1
3359 nvidia-settings -a myserver:0[gpu:0]/FrameLockTestSignal=0
3362 3. 1 System, 4 GPUs, 2 Frame Lock boards and 2 display devices per GPU
3363 syncing from the first GPU's display device:
3365 # - Make sure frame lock sync is disabled
3366 nvidia-settings -a [gpu:0]/FrameLockEnable=0
3367 nvidia-settings -a [gpu:1]/FrameLockEnable=0
3368 nvidia-settings -a [gpu:2]/FrameLockEnable=0
3369 nvidia-settings -a [gpu:3]/FrameLockEnable=0
3371 # - Query the enabled displays on the GPUs
3372 nvidia-settings -q [gpu:0]/EnabledDisplays
3373 nvidia-settings -q [gpu:1]/EnabledDisplays
3374 nvidia-settings -q [gpu:2]/EnabledDisplays
3375 nvidia-settings -q [gpu:3]/EnabledDisplays
3377 # - Check the refresh rate is the same for all displays
3378 nvidia-settings -q [gpu:0]/RefreshRate
3379 nvidia-settings -q [gpu:1]/RefreshRate
3380 nvidia-settings -q [gpu:2]/RefreshRate
3381 nvidia-settings -q [gpu:3]/RefreshRate
3383 # - Make sure the display device we want as master is masterable
3384 nvidia-settings -q myserver:0[gpu:0]/FrameLockMasterable
3386 # - Set the master display device (CRT-0)
3387 nvidia-settings -a [gpu:0]/FrameLockMaster=0x00000001
3389 # - Disable the house sync signal on the master device
3390 nvidia-settings -a [framelock:0]/FrameLockUseHouseSync=1
3392 # - Set the slave display devices
3393 nvidia-settings -a [gpu:0]/FrameLockSlaves=0x00000002 # CRT-1
3394 nvidia-settings -a [gpu:1]/FrameLockSlaves=0x00000003 # CRT-0 and CRT-1
3395 nvidia-settings -a [gpu:2]/FrameLockSlaves=0x00000003 # CRT-0 and CRT-1
3396 nvidia-settings -a [gpu:3]/FrameLockSlaves=0x00000003 # CRT-0 and CRT-1
3398 # - Enable framelocking on master GPU
3399 nvidia-settings -a [gpu:0]/FrameLockEnable=1
3401 # - Enable framelocking on slave devices
3402 nvidia-settings -a [gpu:1]/FrameLockEnable=1
3403 nvidia-settings -a [gpu:2]/FrameLockEnable=1
3404 nvidia-settings -a [gpu:3]/FrameLockEnable=1
3406 # - Toggle the test signal
3407 nvidia-settings -a [gpu:0]/FrameLockTestSignal=1
3408 nvidia-settings -a [gpu:0]/FrameLockTestSignal=0
3413 21I. LEVERAGING FRAME LOCK/GENLOCK IN OPENGL
3415 With the GLX_NV_swap_group extension, OpenGL applications can be implemented
3416 to join a group of applications within a system for local swap sync, and bind
3417 the group to a barrier for swap sync across a frame lock group. A universal
3418 frame counter is also provided to promote synchronization across applications.
3421 21J. FRAME LOCK RESTRICTIONS:
3423 The following restrictions must be met for enabling frame lock:
3425 1. All display devices set as client in a frame lock group must have the
3426 same mode timings as the server (master) display device. If a House Sync
3427 signal is used (instead of internal timings), all client display devices
3428 must be set to have the same refresh rate as the incoming house sync
3431 2. All X Screens (driving the selected client/server display devices) must
3432 have the same stereo setting. See Appendix F for instructions on how to
3433 set the stereo X option.
3435 3. The frame lock server (master) display device must be on a GPU on the
3436 primary connector to a G-Sync device.
3438 4. If connecting a single GPU to a G-Sync device, the primary connector must
3441 5. In configurations with more than one display device per GPU, we recommend
3442 enabling frame lock on all display devices on those GPUs.
3446 21K. SUPPORTED FRAME LOCK CONFIGURATIONS:
3448 The following configurations are currently supported:
3450 1. Basic Frame Lock: Single GPU, Single X Screen, Single Display Device with
3451 or without OpenGL applications that make use of Quad-Buffered Stereo
3452 and/or the GLX_NV_swap_group extension.
3454 2. Frame Lock + TwinView: Single GPU, Single X Screen, Multiple Display
3455 Devices with or without OpenGL applications that make use of
3456 Quad-Buffered Stereo and/or the GLX_NV_swap_group extension.
3458 3. Frame Lock + Xinerama: 1 or more GPU(s), Multiple X Screens, Multiple
3459 Display Devices with or without OpenGL applications that make use of
3460 Quad-Buffered Stereo and/or the GLX_NV_swap_group extension.
3462 4. Frame Lock + TwinView + Xinerama: 1 or more GPU(s), Multiple X Screens,
3463 Multiple Display Devices with or without OpenGL applications that make
3464 use of Quad-Buffered Stereo and/or the GLX_NV_swap_group extension.
3466 5. Frame Lock + SLI SFR, AFR, or AA: 2 GPUs, Single X Screen, Single Display
3467 Device with either OpenGL applications that make use of Quad-Buffered
3468 Stereo or the GLX_NV_swap_group extension. Note that for Frame Lock + SLI
3469 Frame Rendering applications that make use of both Quad-Buffered Stereo
3470 and the GLX_NV_swap_group extension are not supported. Note that only
3471 2-GPU SLI configurations are currently supported.
3473 6. Frame Lock + Multi-GPU SFR, AFR, or AA: 2 GPUs, Single X Screen, Single
3474 Display Device with either OpenGL applications that make use of
3475 Quad-Buffered Stereo or the GLX_NV_swap_group extension. Note that for
3476 Frame Lock + Multi-GPU Frame Rendering applications that make use of both
3477 Quad-Buffered Stereo and the GLX_NV_swap_group extension are not
3481 ______________________________________________________________________________
3483 Chapter 22. Configuring Depth 30 Displays
3484 ______________________________________________________________________________
3486 This driver release supports X screens with screen depths of 30 bits per pixel
3487 (10 bits per color component) on NVIDIA Quadro GPUs based on G80 and higher
3488 chip architectures. This provides about 1 billion possible colors, allowing
3489 for higher color precision and smoother gradients.
3491 When displaying a depth 30 image on a digital flat panel, the color data will
3492 be dithered to 8 or 6 bits per pixel, depending on the capabilities of the
3493 flat panel. VGA outputs can display the full 10 bit range of colors.
3495 To work reliably, depth 30 requires X.org 7.3 or higher.
3497 NOTE: X servers starting with X.org 7.3 rely on a library called libpixman to
3498 perform software rendering. As of this writing, the officially released
3499 version of this library will crash when it encouters depth 30 drawables. To be
3500 able to run X at this depth, you will need to download, compile, and install
3501 the "wide-composite" development branch from the freedesktop.org pixman git
3502 repository. Please see the freedesktop.org and git documentation for
3503 instructions on how to download and compile development branches.
3505 In addition to the above software requirements, many X applications and
3506 toolkits do not understand depth 30 visuals as of this writing. Some programs
3507 may work correctly, some may work but display incorrect colors, and some may
3508 simply fail to run. In particular, many OpenGL applications request 8 bits of
3509 alpha when searching for FBConfigs. Since depth 30 visuals have only 2 bits of
3510 alpha, no suitable FBConfigs will be found and such applications will fail to
3513 ______________________________________________________________________________
3515 Chapter 23. NVIDIA Contact Info and Additional Resources
3516 ______________________________________________________________________________
3518 If you believe that you have found a bug or have a problem that you need
3519 assitance with and cannot find the solution elsewhere, or if you have found
3520 innaccuracies in this document, send email to freebsd-gfx-bugs@nvidia.com
3524 Additional Resources
3526 XFree86 Video Timings HOWTO
3528 http://www.tldp.org/HOWTO/XFree86-Video-Timings-HOWTO/index.html
3530 The X.Org Foundation
3536 http://www.opengl.org/
3539 ______________________________________________________________________________
3542 ______________________________________________________________________________
3544 The port of the NVIDIA driver to FreeBSD is due in no small part to the many
3545 contributions of Christian Zander <zander 'at' mail.minion.de> and Matthew N.
3546 Dodd <mdodd 'at' freebsd.org>.
3548 ______________________________________________________________________________
3550 Chapter 25. Acknowledgements
3551 ______________________________________________________________________________
3553 The driver splash screen is decoded using 'libpng':
3554 http://libpng.org/pub/png/libpng.html
3556 This NVIDIA FreeBSD driver contains code from the int10 module of the X.Org
3559 The BSD implementations of the following compiler intrinsics are used for
3560 better portability: __udivdi3, __umoddi3, __moddi3, __ucmpdi2, __cmpdi2,
3561 __fixunssfdi, and __fixunsdfdi.
3563 ______________________________________________________________________________
3565 Appendix E. Supported NVIDIA GPU Products
3566 ______________________________________________________________________________
3568 For the most complete and accurate listing of supported GPUs, please see the
3569 Supported Products List, available from the NVIDIA FreeBSD x86 Graphics Driver
3570 download page. Please go to http://www.nvidia.com/object/unix.html, follow the
3571 Archive link under the FreeBSD x86 heading, follow the link for the 169.07
3572 driver, and then go to the Supported Products List.
3575 E1. NVIDIA GEFORCE GPUS
3578 NVIDIA GPU product Device PCI ID
3579 ------------------------------------------------------ ---------------
3580 GeForce 6800 Ultra 0x0040
3582 GeForce 6800 LE 0x0042
3583 GeForce 6800 XE 0x0043
3584 GeForce 6800 XT 0x0044
3585 GeForce 6800 GT 0x0045
3586 GeForce 6800 GT 0x0046
3587 GeForce 6800 GS 0x0047
3588 GeForce 6800 XT 0x0048
3589 GeForce 7800 GTX 0x0090
3590 GeForce 7800 GTX 0x0091
3591 GeForce 7800 GT 0x0092
3592 GeForce 7800 GS 0x0093
3593 GeForce 7800 SLI 0x0095
3594 GeForce Go 7800 0x0098
3595 GeForce Go 7800 GTX 0x0099
3596 GeForce 6800 GS 0x00C0
3598 GeForce 6800 LE 0x00C2
3599 GeForce 6800 XT 0x00C3
3600 GeForce Go 6800 0x00C8
3601 GeForce Go 6800 Ultra 0x00C9
3603 GeForce 6600 GT 0x00F1
3606 GeForce 6600 LE 0x00F4
3607 GeForce 7800 GS 0x00F5
3608 GeForce 6800 GS 0x00F6
3609 GeForce 6800 Ultra 0x00F9
3610 GeForce PCX 5750 0x00FA
3611 GeForce PCX 5900 0x00FB
3612 GeForce PCX 5300 0x00FC
3613 GeForce 6600 GT 0x0140
3615 GeForce 6600 LE 0x0142
3616 GeForce 6600 VE 0x0143
3617 GeForce Go 6600 0x0144
3618 GeForce 6610 XL 0x0145
3619 GeForce Go 6600 TE/6200 TE 0x0146
3620 GeForce 6700 XL 0x0147
3621 GeForce Go 6600 0x0148
3622 GeForce Go 6600 GT 0x0149
3625 GeForce 6200 TurboCache(TM) 0x0161
3626 GeForce 6200SE TurboCache(TM) 0x0162
3627 GeForce 6200 LE 0x0163
3628 GeForce Go 6200 0x0164
3629 GeForce Go 6400 0x0166
3630 GeForce Go 6200 0x0167
3631 GeForce Go 6400 0x0168
3633 GeForce 7100 GS 0x016A
3634 GeForce 8800 GTX 0x0191
3635 GeForce 8800 GTS 0x0193
3636 GeForce 8800 Ultra 0x0194
3638 GeForce 7350 LE 0x01D0
3639 GeForce 7300 LE 0x01D1
3640 GeForce 7300 SE/7200 GS 0x01D3
3641 GeForce Go 7200 0x01D6
3642 GeForce Go 7300 0x01D7
3643 GeForce Go 7400 0x01D8
3644 GeForce 7500 LE 0x01DD
3645 GeForce 7300 GS 0x01DF
3647 GeForce 6800 LE 0x0212
3648 GeForce 6800 GT 0x0215
3649 GeForce 6800 XT 0x0218
3651 GeForce 6200 A-LE 0x0222
3653 GeForce 6150 LE 0x0241
3655 GeForce Go 6150 0x0244
3656 GeForce Go 6100 0x0247
3657 GeForce 7900 GTX 0x0290
3658 GeForce 7900 GT/GTO 0x0291
3659 GeForce 7900 GS 0x0292
3660 GeForce 7950 GX2 0x0293
3661 GeForce 7950 GX2 0x0294
3662 GeForce 7950 GT 0x0295
3663 GeForce Go 7950 GTX 0x0297
3664 GeForce Go 7900 GS 0x0298
3665 GeForce Go 7900 GTX 0x0299
3666 GeForce 7600 GT 0x02E0
3667 GeForce 7600 GS 0x02E1
3668 GeForce 7900 GS 0x02E3
3669 GeForce 7950 GT 0x02E4
3670 GeForce FX 5800 Ultra 0x0301
3671 GeForce FX 5800 0x0302
3672 GeForce FX 5600 Ultra 0x0311
3673 GeForce FX 5600 0x0312
3674 GeForce FX 5600XT 0x0314
3675 GeForce FX Go5600 0x031A
3676 GeForce FX Go5650 0x031B
3677 GeForce FX 5200 0x0320
3678 GeForce FX 5200 Ultra 0x0321
3679 GeForce FX 5200 0x0322
3680 GeForce FX 5200LE 0x0323
3681 GeForce FX Go5200 0x0324
3682 GeForce FX Go5250 0x0325
3683 GeForce FX 5500 0x0326
3684 GeForce FX 5100 0x0327
3685 GeForce FX Go5200 32M/64M 0x0328
3686 GeForce FX Go53xx 0x032C
3687 GeForce FX Go5100 0x032D
3688 GeForce FX 5900 Ultra 0x0330
3689 GeForce FX 5900 0x0331
3690 GeForce FX 5900XT 0x0332
3691 GeForce FX 5950 Ultra 0x0333
3692 GeForce FX 5900ZT 0x0334
3693 GeForce FX 5700 Ultra 0x0341
3694 GeForce FX 5700 0x0342
3695 GeForce FX 5700LE 0x0343
3696 GeForce FX 5700VE 0x0344
3697 GeForce FX Go5700 0x0347
3698 GeForce FX Go5700 0x0348
3699 GeForce 7650 GS 0x0390
3700 GeForce 7600 GT 0x0391
3701 GeForce 7600 GS 0x0392
3702 GeForce 7300 GT 0x0393
3703 GeForce 7600 LE 0x0394
3704 GeForce 7300 GT 0x0395
3705 GeForce Go 7600 0x0398
3706 GeForce Go 7600 GT 0x0399
3707 GeForce 6150SE nForce 430 0x03D0
3708 GeForce 6100 nForce 405 0x03D1
3709 GeForce 6100 nForce 400 0x03D2
3710 GeForce 6100 nForce 420 0x03D5
3711 GeForce 8600 GTS 0x0400
3712 GeForce 8600 GT 0x0402
3713 GeForce 8400 GS 0x0404
3714 GeForce 8600M GT 0x0407
3715 GeForce 8700M GT 0x0409
3716 GeForce 8400 SE 0x0420
3717 GeForce 8500 GT 0x0421
3718 GeForce 8400 GS 0x0422
3719 GeForce 8300 GS 0x0423
3720 GeForce 8600M GS 0x0425
3721 GeForce 8400M GT 0x0426
3722 GeForce 8400M GS 0x0427
3723 GeForce 8400M G 0x0428
3724 GeForce 7150M / nForce 630M 0x0531
3725 GeForce 7000M / nForce 610M 0x0533
3726 GeForce 7050 PV / NVIDIA nForce 630a 0x053A
3727 GeForce 7050 PV / NVIDIA nForce 630a 0x053B
3728 GeForce 7025 / NVIDIA nForce 630a 0x053E
3729 GeForce 8800 GTS 512 0x0600
3730 GeForce 8800M GTS 0x0609
3731 GeForce 8800M GTX 0x060C
3732 GeForce 8800 GT 0x0611
3736 E2. NVIDIA QUADRO GPUS
3739 NVIDIA GPU product Device PCI ID
3740 ------------------------------------------------------ ---------------
3741 Quadro FX 4000 0x004E
3742 Quadro FX 4500 0x009D
3743 Quadro FX Go1400 0x00CC
3744 Quadro FX 3450/4000 SDI 0x00CD
3745 Quadro FX 1400 0x00CE
3746 Quadro FX 4400/Quadro FX 3400 0x00F8
3747 Quadro FX 330 0x00FC
3748 Quadro NVS 280 PCI-E/Quadro FX 330 0x00FD
3749 Quadro FX 1300 0x00FE
3750 Quadro NVS 440 0x014A
3751 Quadro FX 540M 0x014C
3752 Quadro FX 550 0x014D
3753 Quadro FX 540 0x014E
3754 Quadro NVS 285 0x0165
3755 Quadro FX 5600 0x019D
3756 Quadro FX 4600 0x019E
3757 Quadro NVS 110M 0x01D7
3758 Quadro NVS 110M 0x01DA
3759 Quadro NVS 120M 0x01DB
3760 Quadro FX 350M 0x01DC
3761 Quadro FX 350 0x01DE
3762 Quadro NVS 210S / NVIDIA GeForce 6150LE 0x0245
3763 Quadro FX 2500M 0x029A
3764 Quadro FX 1500M 0x029B
3765 Quadro FX 5500 0x029C
3766 Quadro FX 3500 0x029D
3767 Quadro FX 1500 0x029E
3768 Quadro FX 4500 X2 0x029F
3769 Quadro FX 2000 0x0308
3770 Quadro FX 1000 0x0309
3771 Quadro FX Go700 0x031C
3772 Quadro NVS 55/280 PCI 0x032A
3773 Quadro FX 500/FX 600 0x032B
3774 Quadro FX 3000 0x0338
3775 Quadro FX 700 0x033F
3776 Quadro FX Go1000 0x034C
3777 Quadro FX 1100 0x034E
3778 Quadro FX 560 0x039E
3779 Quadro FX 370 0x040A
3780 Quadro NVS 320M 0x040B
3781 Quadro FX 570M 0x040C
3782 Quadro FX 1600M 0x040D
3783 Quadro FX 570 0x040E
3784 Quadro FX 1700 0x040F
3785 Quadro NVS 140M 0x0429
3786 Quadro NVS 130M 0x042A
3787 Quadro NVS 135M 0x042B
3788 Quadro FX 360M 0x042D
3789 Quadro NVS 290 0x042F
3790 Quadro FX 3700 0x061A
3793 Below are the legacy GPUs that are no longer supported in the unified driver.
3794 These GPUs will continue to be maintained through the special legacy NVIDIA
3795 GPU driver releases.
3797 The 96.43.xx driver supports the following set of GPUs:
3800 NVIDIA GPU product Device PCI ID
3801 ---------------------------------- ----------------------------------
3802 GeForce2 MX/MX 400 0x0110
3803 GeForce2 MX 100/200 0x0111
3805 Quadro2 MXR/EX/Go 0x0113
3806 GeForce4 MX 460 0x0170
3807 GeForce4 MX 440 0x0171
3808 GeForce4 MX 420 0x0172
3809 GeForce4 MX 440-SE 0x0173
3810 GeForce4 440 Go 0x0174
3811 GeForce4 420 Go 0x0175
3812 GeForce4 420 Go 32M 0x0176
3813 GeForce4 460 Go 0x0177
3814 Quadro4 550 XGL 0x0178
3815 GeForce4 440 Go 64M 0x0179
3816 Quadro NVS 400 0x017A
3817 Quadro4 500 GoGL 0x017C
3818 GeForce4 410 Go 16M 0x017D
3819 GeForce4 MX 440 with AGP8X 0x0181
3820 GeForce4 MX 440SE with AGP8X 0x0182
3821 GeForce4 MX 420 with AGP8X 0x0183
3822 GeForce4 MX 4000 0x0185
3823 Quadro4 580 XGL 0x0188
3824 Quadro NVS 280 SD 0x018A
3825 Quadro4 380 XGL 0x018B
3826 Quadro NVS 50 PCI 0x018C
3827 GeForce2 Integrated GPU 0x01A0
3828 GeForce4 MX Integrated GPU 0x01F0
3830 GeForce3 Ti 200 0x0201
3831 GeForce3 Ti 500 0x0202
3833 GeForce4 Ti 4600 0x0250
3834 GeForce4 Ti 4400 0x0251
3835 GeForce4 Ti 4200 0x0253
3836 Quadro4 900 XGL 0x0258
3837 Quadro4 750 XGL 0x0259
3838 Quadro4 700 XGL 0x025B
3839 GeForce4 Ti 4800 0x0280
3840 GeForce4 Ti 4200 with AGP8X 0x0281
3841 GeForce4 Ti 4800 SE 0x0282
3842 GeForce4 4200 Go 0x0286
3843 Quadro4 980 XGL 0x0288
3844 Quadro4 780 XGL 0x0289
3845 Quadro4 700 GoGL 0x028C
3848 The 71.86.xx driver supports the following set of GPUs:
3851 NVIDIA GPU product Device PCI ID
3852 ---------------------------------- ----------------------------------
3854 RIVA TNT2/TNT2 Pro 0x0028
3855 RIVA TNT2 Ultra 0x0029
3856 Vanta/Vanta LT 0x002C
3857 RIVA TNT2 Model 64/Model 64 Pro 0x002D
3862 GeForce2 GTS/GeForce2 Pro 0x0150
3864 GeForce2 Ultra 0x0152
3868 ______________________________________________________________________________
3870 Appendix F. X Config Options
3871 ______________________________________________________________________________
3873 The following driver options are supported by the NVIDIA X driver. They may be
3874 specified either in the Screen or Device sections of the X config file.
3878 Option "NvAGP" "integer"
3880 Configure AGP support. Integer argument can be one of:
3883 -------------- ---------------------------------------------------
3885 1 use NVIDIA internal AGP support, if possible
3886 2 use AGPGART, if possible
3887 3 use any AGP support (try AGPGART, then NVIDIA AGP)
3889 Note that NVIDIA internal AGP support cannot work if AGPGART is either
3890 statically compiled into your kernel or is built as a module and loaded
3891 into your kernel. See Chapter 9 for details. Default: 3.
3893 Option "NoLogo" "boolean"
3895 Disable drawing of the NVIDIA logo splash screen at X startup. Default:
3896 the logo is drawn for screens with depth 24.
3898 Option "LogoPath" "string"
3900 Sets the path to the PNG file to be used as the logo splash screen at X
3901 startup. If the PNG file specified has a bKGD (background color) chunk,
3902 then the screen is cleared to the color it specifies. Otherwise, the
3903 screen is cleared to black. The logo file must be owned by root and must
3904 not be writable by a non-root group. Note that a logo is only displayed
3905 for screens with depth 24. Default: The built-in NVIDIA logo is used.
3907 Option "RenderAccel" "boolean"
3909 Enable or disable hardware acceleration of the RENDER extension. Default:
3910 hardware acceleration of the RENDER extension is enabled.
3912 Option "NoRenderExtension" "boolean"
3914 Disable the RENDER extension. Other than recompiling it, the X server does
3915 not seem to have another way of disabling this. Fortunately, we can
3916 control this from the driver so we export this option. This is useful in
3917 depth 8 where RENDER would normally steal most of the default colormap.
3918 Default: RENDER is offered when possible.
3920 Option "UBB" "boolean"
3922 Enable or disable the Unified Back Buffer on Quadro-based GPUs (Quadro4
3923 NVS excluded); see Chapter 17 for a description of UBB. This option has no
3924 effect on non-Quadro GPU products. Default: UBB is on for Quadro GPUs.
3926 Option "NoFlip" "boolean"
3928 Disable OpenGL flipping; see Chapter 17 for a description. Default: OpenGL
3929 will swap by flipping when possible.
3931 Option "Dac8Bit" "boolean"
3933 Most Quadro products by default use a 10-bit color look-up table (LUT);
3934 setting this option to TRUE forces these GPUs to use an 8-bit (LUT).
3935 Default: a 10-bit LUT is used, when available.
3937 Option "Overlay" "boolean"
3939 Enables RGB workstation overlay visuals. This is only supported on Quadro
3940 GPUs (Quadro NVS GPUs excluded) in depth 24. This option causes the server
3941 to advertise the SERVER_OVERLAY_VISUALS root window property and GLX will
3942 report single- and double-buffered, Z-buffered 16-bit overlay visuals. The
3943 transparency key is pixel 0x0000 (hex). There is no gamma correction
3944 support in the overlay plane. This feature requires XFree86 version 4.1.0
3945 or newer, or the X.Org X server. When TwinView is enabled, or the X screen
3946 is either wider than 2046 pixels or taller than 2047, the overlay may be
3947 emulated with a substantial performance penalty. RGB workstation overlays
3948 are not supported when the Composite extension is enabled. Dynamic
3949 TwinView is disabled when Overlays are enabled. Default: off.
3951 UBB must be enabled when overlays are enabled (this is the default
3954 Option "CIOverlay" "boolean"
3956 Enables Color Index workstation overlay visuals with identical
3957 restrictions to Option "Overlay" above. The server will offer visuals both
3958 with and without a transparency key. These are depth 8 PseudoColor
3959 visuals. Enabling Color Index overlays on X servers older than XFree86 4.3
3960 will force the RENDER extension to be disabled due to bugs in the RENDER
3961 extension in older X servers. Color Index workstation overlays are not
3962 supported when the Composite extension is enabled. Default: off.
3964 UBB must be enabled when overlays are enabled (this is the default
3967 Option "TransparentIndex" "integer"
3969 When color index overlays are enabled, use this option to choose which
3970 pixel is used for the transparent pixel in visuals featuring transparent
3971 pixels. This value is clamped between 0 and 255 (Note: some applications
3972 such as Alias's Maya require this to be zero in order to work correctly).
3975 Option "OverlayDefaultVisual" "boolean"
3977 When overlays are used, this option sets the default visual to an overlay
3978 visual thereby putting the root window in the overlay. This option is not
3979 recommended for RGB overlays. Default: off.
3981 Option "EmulatedOverlaysTimerMs" "integer"
3983 Enables the use of a timer within the X server to perform the updates to
3984 the emulated overlay or CI overlay. This option can be used to improve the
3985 performance of the emulated or CI overlays by reducing the frequency of
3986 the updates. The value specified indicates the desired number of
3987 milliseconds between overlay updates. To disable the use of the timer
3988 either leave the option unset or set it to 0. Default: off.
3990 Option "EmulatedOverlaysThreshold" "boolean"
3992 Enables the use of a threshold within the X server to perform the updates
3993 to the emulated overlay or CI overlay. The emulated or CI overlay updates
3994 can be defered but this threshold will limit the number of defered OpenGL
3995 updates allowed before the overlay is updated. This option can be used to
3996 trade off performance and animation quality. Default: on.
3998 Option "EmulatedOverlaysThresholdValue" "integer"
4000 Controls the threshold used in updating the emulated or CI overlays. This
4001 is used in conjunction with the EmulatedOverlaysThreshold option to trade
4002 off performance and animation quality. Higher values for this option favor
4003 performance over quality. Setting low values of this option will not cause
4004 the overlay to be updated more often than the frequence specified by the
4005 EmulatedOverlaysTimerMs option. Default: 5.
4007 Option "RandRRotation" "boolean"
4009 Enable rotation support for the XRandR extension. This allows use of the
4010 XRandR X server extension for configuring the screen orientation through
4011 rotation. This feature is supported using depth 24. This requires an X.Org
4012 X 6.8.1 or newer X server. This feature does not work with hardware
4013 overlays; emulated overlays will be used instead at a substantial
4014 performance penalty. See Chapter 14 for details. Default: off.
4016 Option "Rotate" "string"
4018 Enable static rotation support. Unlike the RandRRotation option above,
4019 this option takes effect as soon as the X server is started and will work
4020 with older versions of X. This feature is supported using depth 24. This
4021 feature does not work with hardware overlays; emulated overlays will be
4022 used instead at a substantial performance penalty. This option is not
4023 compatible with the RandR extension. Valid rotations are "normal", "left",
4024 "inverted", and "right". Default: off.
4026 Option "AllowDDCCI" "boolean"
4028 Enables DDC/CI support in the NV-CONTROL X extension. DDC/CI is a
4029 mechanism for communication between your computer and your display device.
4030 This can be used to set the values normally controlled through your
4031 display device's On Screen Display. See the DDC/CI NV-CONTROL attributes
4032 in 'NVCtrl.h' and functions in 'NVCtrlLib.h' in the 'nvidia-settings'
4033 source code. Default: off (DDC/CI is disabled).
4035 Option "SWCursor" "boolean"
4037 Enable or disable software rendering of the X cursor. Default: off.
4039 Option "HWCursor" "boolean"
4041 Enable or disable hardware rendering of the X cursor. Default: on.
4043 Option "CursorShadow" "boolean"
4045 Enable or disable use of a shadow with the hardware accelerated cursor;
4046 this is a black translucent replica of your cursor shape at a given offset
4047 from the real cursor. Default: off (no cursor shadow).
4049 Option "CursorShadowAlpha" "integer"
4051 The alpha value to use for the cursor shadow; only applicable if
4052 CursorShadow is enabled. This value must be in the range [0, 255] -- 0 is
4053 completely transparent; 255 is completely opaque. Default: 64.
4055 Option "CursorShadowXOffset" "integer"
4057 The offset, in pixels, that the shadow image will be shifted to the right
4058 from the real cursor image; only applicable if CursorShadow is enabled.
4059 This value must be in the range [0, 32]. Default: 4.
4061 Option "CursorShadowYOffset" "integer"
4063 The offset, in pixels, that the shadow image will be shifted down from the
4064 real cursor image; only applicable if CursorShadow is enabled. This value
4065 must be in the range [0, 32]. Default: 2.
4067 Option "ConnectedMonitor" "string"
4069 Allows you to override what the NVIDIA kernel module detects is connected
4070 to your graphics card. This may be useful, for example, if you use a KVM
4071 (keyboard, video, mouse) switch and you are switched away when X is
4072 started. In such a situation, the NVIDIA kernel module cannot detect what
4073 display devices are connected, and the NVIDIA X driver assumes you have a
4076 Valid values for this option are "CRT" (cathode ray tube), "DFP" (digital
4077 flat panel), or "TV" (television); if using TwinView, this option may be a
4078 comma-separated list of display devices; e.g.: "CRT, CRT" or "CRT, DFP".
4080 It is generally recommended to not use this option, but instead use the
4081 "UseDisplayDevice" option.
4083 NOTE: anything attached to a 15 pin VGA connector is regarded by the
4084 driver as a CRT. "DFP" should only be used to refer to digital flat panels
4085 connected via a DVI port.
4087 Default: string is NULL (the NVIDIA driver will detect the connected
4090 Option "UseDisplayDevice" "string"
4092 When assigning display devices to X screens, the NVIDIA X driver by
4093 default assigns display devices in the order they are found (looking first
4094 at CRTs, then at DFPs, and finally at TVs). This option can be used to
4095 override this assignment. For example, if both a CRT and a DFP are
4096 connected, you could specify:
4098 Option "UseDisplayDevice" "DFP"
4100 to make the X screen use the DFP, even though it would have used a CRT by
4103 Note the subtle difference between this option and the "ConnectedMonitor"
4104 option: the "ConnectedMonitor" option overrides what display devices are
4105 actually detected, while the "UseDisplayDevice" option controls which of
4106 the detected display devices will be used on this X screen.
4108 Additionally, the special value "none" can be specified for the
4109 "UseDisplayDevice" option. When this value is given, any programming of
4110 the display hardware is disabled. The NVIDIA driver will not perform any
4111 mode validation or modesetting for this X screen. This is intended for use
4112 in conjunction with CUDA or in remote graphics solutions such as VNC or
4113 Hewlett Packard's Remote Graphics Software (RGS). This functionality is
4114 only available on Quadro and Tesla GPUs.
4116 Note the following restrictions for setting the "UseDisplayDevice" to
4119 o OpenGL SyncToVBlank will have no effect.
4121 o You must also explicitly specify the Virtual screen size for your X
4122 screen (see the xorg.conf(5x) or XF86Config(5x) manpages for the
4123 'Virtual' option, or the nvidia-xconfig(1) manpage for the
4124 '--virtual' commandline option); the Virtual screen size must be at
4125 least 304x200, and the width must be a multiple of 8.
4127 o None of Stereo, Overlay, CIOverlay, or SLI are allowed when
4128 "UseDisplayDevice" is set to "none".
4131 Option "UseEdidFreqs" "boolean"
4133 This option controls whether the NVIDIA X driver will use the HorizSync
4134 and VertRefresh ranges given in a display device's EDID, if any. When
4135 UseEdidFreqs is set to True, EDID-provided range information will override
4136 the HorizSync and VertRefresh ranges specified in the Monitor section. If
4137 a display device does not provide an EDID, or the EDID does not specify an
4138 hsync or vrefresh range, then the X server will default to the HorizSync
4139 and VertRefresh ranges specified in the Monitor section of your X config
4140 file. These frequency ranges are used when validating modes for your
4143 Default: True (EDID frequencies will be used)
4145 Option "UseEDID" "boolean"
4147 By default, the NVIDIA X driver makes use of a display device's EDID, when
4148 available, during construction of its mode pool. The EDID is used as a
4149 source for possible modes, for valid frequency ranges, and for collecting
4150 data on the physical dimensions of the display device for computing the
4151 DPI (see Appendix I). However, if you wish to disable the driver's use of
4152 the EDID, you can set this option to False:
4154 Option "UseEDID" "FALSE"
4156 Note that, rather than globally disable all uses of the EDID, you can
4157 individually disable each particular use of the EDID; e.g.,
4159 Option "UseEDIDFreqs" "FALSE"
4160 Option "UseEDIDDpi" "FALSE"
4161 Option "ModeValidation" "NoEdidModes"
4163 Default: True (use EDID).
4165 Option "IgnoreEDID" "boolean"
4167 This option is deprecated, and no longer affects behavior of the X driver.
4168 See the "UseEDID" option for details.
4170 Option "NoDDC" "boolean"
4172 Synonym for "IgnoreEDID". This option is deprecated, and no longer affects
4173 behavior of the X driver. See the "UseEDID" option for details.
4175 Option "UseInt10Module" "boolean"
4177 Enable use of the X Int10 module to soft-boot all secondary cards, rather
4178 than POSTing the cards through the NVIDIA kernel module. Default: off
4179 (POSTing is done through the NVIDIA kernel module).
4181 Option "TwinView" "boolean"
4183 Enable or disable TwinView. See Chapter 10 for details. Default: off
4184 (TwinView is disabled).
4186 Option "TwinViewOrientation" "string"
4188 Controls the relationship between the two display devices when using
4189 TwinView. Takes one of the following values: "RightOf" "LeftOf" "Above"
4190 "Below" "Clone". See Chapter 10 for details. Default: string is NULL.
4192 Option "SecondMonitorHorizSync" "range(s)"
4194 This option is like the HorizSync entry in the Monitor section, but is for
4195 the second monitor when using TwinView. See Chapter 10 for details.
4198 Option "SecondMonitorVertRefresh" "range(s)"
4200 This option is like the VertRefresh entry in the Monitor section, but is
4201 for the second monitor when using TwinView. See Chapter 10 for details.
4204 Option "MetaModes" "string"
4206 This option describes the combination of modes to use on each monitor when
4207 using TwinView. See Chapter 10 for details. Default: string is NULL.
4209 Option "NoTwinViewXineramaInfo" "boolean"
4211 When in TwinView, the NVIDIA X driver normally provides a Xinerama
4212 extension that X clients (such as window managers) can use to discover the
4213 current TwinView configuration, such as where each display device is
4214 positioned within the X screen. Some window mangers get confused by this
4215 information, so this option is provided to disable this behavior. Default:
4216 false (TwinView Xinerama information is provided).
4218 Option "TwinViewXineramaInfoOrder" "string"
4220 When the NVIDIA X driver provides TwinViewXineramaInfo (see the
4221 NoTwinViewXineramaInfo X config option), it by default reports the
4222 currently enabled display devices in the order "CRT, DFP, TV". The
4223 TwinViewXineramaInfoOrder X config option can be used to override this
4226 The option string is a comma-separated list of display device names. The
4227 display device names can either be general (e.g, "CRT", which identifies
4228 all CRTs), or specific (e.g., "CRT-1", which identifies a particular CRT).
4229 Not all display devices need to be identified in the option string;
4230 display devices that are not listed will be implicitly appended to the end
4231 of the list, in their default order.
4233 Note that TwinViewXineramaInfoOrder tracks all display devices that could
4234 possibly be connected to the GPU, not just the ones that are currently
4235 enabled. When reporting the Xinerama information, the NVIDIA X driver
4236 walks through the display devices in the order specified, only reporting
4237 enabled display devices.
4243 "DFP-1, DFP-0, TV, CRT"
4245 In the first example, any enabled DFPs would be reported first (any
4246 enabled CRTs or TVs would be reported afterwards). In the second example,
4247 any enabled TVs would be reported first, then any enabled DFPs (any
4248 enabled CRTs would be reported last). In the last example, if DFP-1 were
4249 enabled, it would be reported first, then DFP-0, then any enabled TVs, and
4250 then any enabled CRTs; finally, any other enabled DFPs would be reported.
4252 Default: "CRT, DFP, TV"
4254 Option "TwinViewXineramaInfoOverride" "string"
4256 This option overrides the values reported by NVIDIA's TwinView Xinerama
4257 implementation. This disregards the actual display devices used by the X
4258 screen and any order specified in TwinViewXineramaInfoOrder.
4260 The option string is interpreted as a comma-separated list of regions,
4261 specified as '[width]x[height]+[xoffset]+[yoffset]'. The regions' sizes
4262 and offsets are not validated against the X screen size, but are directly
4263 reported to any Xinerama client.
4267 "1600x1200+0+0, 1600x1200+1600+0"
4268 "1024x768+0+0, 1024x768+1024+0, 1024x768+0+768, 1024x768+1024+768"
4271 Option "TVStandard" "string"
4273 See Chapter 13 for details on configuring TV-out.
4275 Option "TVOutFormat" "string"
4277 See Chapter 13 for details on configuring TV-out.
4279 Option "TVOverScan" "Decimal value in the range 0.0 to 1.0"
4281 Valid values are in the range 0.0 through 1.0; See Chapter 13 for details
4282 on configuring TV-out.
4284 Option "Stereo" "integer"
4286 Enable offering of quad-buffered stereo visuals on Quadro. Integer
4287 indicates the type of stereo equipment being used:
4290 -------------- ---------------------------------------------------
4291 1 DDC glasses. The sync signal is sent to the
4292 glasses via the DDC signal to the monitor. These
4293 usually involve a passthrough cable between the
4294 monitor and the graphics card. This mode is not
4295 available on G8xGL and higher GPUs.
4296 2 "Blueline" glasses. These usually involve a
4297 passthrough cable between the monitor and graphics
4298 card. The glasses know which eye to display based
4299 on the length of a blue line visible at the bottom
4300 of the screen. When in this mode, the root window
4301 dimensions are one pixel shorter in the Y
4302 dimension than requested. This mode does not work
4303 with virtual root window sizes larger than the
4304 visible root window size (desktop panning). This
4305 mode is not available on G8xGL and higher GPUs.
4306 3 Onboard stereo support. This is usually only found
4307 on professional cards. The glasses connect via a
4308 DIN connector on the back of the graphics card.
4309 4 TwinView clone mode stereo (aka "passive" stereo).
4310 On graphics cards that support TwinView, the left
4311 eye is displayed on the first display, and the
4312 right eye is displayed on the second display. This
4313 is normally used in conjunction with special
4314 projectors to produce 2 polarized images which are
4315 then viewed with polarized glasses. To use this
4316 stereo mode, you must also configure TwinView in
4317 clone mode with the same resolution, panning
4318 offset, and panning domains on each display.
4319 5 Vertical interlaced stereo mode, for use with
4320 SeeReal Stereo Digital Flat Panels.
4321 6 Color interleaved stereo mode, for use with
4322 Sharp3D Stereo Digital Flat Panels.
4324 Stereo is only available on Quadro cards. Stereo options 1, 2, and 3 (aka
4325 "active" stereo) may be used with TwinView if all modes within each
4326 MetaMode have identical timing values. See Chapter 16 for suggestions on
4327 making sure the modes within your MetaModes are identical. The identical
4328 ModeLine requirement is not necessary for Stereo option 4 ("passive"
4329 stereo). Currently, stereo operation may be "quirky" on the original
4330 Quadro (NV10) GPU and left-right flipping may be erratic. We are trying to
4331 resolve this issue for a future release. Default: 0 (Stereo is not
4334 UBB must be enabled when stereo is enabled (this is the default behavior).
4336 Stereo options 1, 2, and 3 (aka "active" stereo) are not supported on
4337 digital flat panels.
4339 Multi-GPU cards (such as the Quadro FX 4500 X2) provide a single connector
4340 for onboard stereo support (option 3), which is tied to the bottommost
4341 GPU. In order to synchronize onboard stereo with the other GPU, you must
4342 use a G-Sync device (see Chapter 21 for details).
4344 Option "AllowDFPStereo" "boolean"
4346 By default, the NVIDIA X driver performs a check which disables active
4347 stereo (stereo options 1, 2, and 3) if the X screen is driving a DFP. The
4348 "AllowDFPStereo" option bypasses this check.
4350 Option "ForceStereoFlipping" "boolean"
4352 Stereo flipping is the process by which left and right eyes are displayed
4353 on alternating vertical refreshes. Normally, stereo flipping is only
4354 performed when a stereo drawable is visible. This option forces stereo
4355 flipping even when no stereo drawables are visible.
4357 This is to be used in conjunction with the "Stereo" option. If "Stereo" is
4358 0, the "ForceStereoFlipping" option has no effect. If otherwise, the
4359 "ForceStereoFlipping" option will force the behavior indicated by the
4360 "Stereo" option, even if no stereo drawables are visible. This option is
4361 useful in a multiple-screen environment in which a stereo application is
4362 run on a different screen than the stereo master.
4367 -------------- ---------------------------------------------------
4368 0 Stereo flipping is not forced. The default
4369 behavior as indicated by the "Stereo" option is
4371 1 Stereo flipping is forced. Stereo is running even
4372 if no stereo drawables are visible. The stereo
4373 mode depends on the value of the "Stereo" option.
4375 Default: 0 (Stereo flipping is not forced). Note that active stereo is not
4376 supported on digital flat panels.
4378 Option "XineramaStereoFlipping" "boolean"
4380 By default, when using Stereo with Xinerama, all physical X screens having
4381 a visible stereo drawable will stereo flip. Use this option to allow only
4382 one physical X screen to stereo flip at a time.
4384 This is to be used in conjunction with the "Stereo" and "Xinerama"
4385 options. If "Stereo" is 0 or "Xinerama" is 0, the "XineramaStereoFlipping"
4386 option has no effect.
4388 If you wish to have all X screens stereo flip all the time, see the
4389 "ForceStereoFlipping" option.
4394 -------------- ---------------------------------------------------
4395 0 Stereo flipping is enabled on one X screen at a
4396 time. Stereo is enabled on the first X screen
4397 having the stereo drawable.
4398 1 Stereo flipping in enabled on all X screens.
4400 Default: 1 (Stereo flipping is enabled on all X screens).
4402 Option "NoBandWidthTest" "boolean"
4404 As part of mode validation, the X driver tests if a given mode fits within
4405 the hardware's memory bandwidth constraints. This option disables this
4406 test. Default: false (the memory bandwidth test is performed).
4408 Option "IgnoreDisplayDevices" "string"
4410 This option tells the NVIDIA kernel module to completely ignore the
4411 indicated classes of display devices when checking what display devices
4412 are connected. You may specify a comma-separated list containing any of
4413 "CRT", "DFP", and "TV". For example:
4415 Option "IgnoreDisplayDevices" "DFP, TV"
4417 will cause the NVIDIA driver to not attempt to detect if any digital flat
4418 panels or TVs are connected. This option is not normally necessary;
4419 however, some video BIOSes contain incorrect information about what
4420 display devices may be connected, or what i2c port should be used for
4421 detection. These errors can cause long delays in starting X. If you are
4422 experiencing such delays, you may be able to avoid this by telling the
4423 NVIDIA driver to ignore display devices which you know are not connected.
4424 NOTE: anything attached to a 15 pin VGA connector is regarded by the
4425 driver as a CRT. "DFP" should only be used to refer to digital flat panels
4426 connected via a DVI port.
4428 Option "MultisampleCompatibility" "boolean"
4430 Enable or disable the use of separate front and back multisample buffers.
4431 Enabling this will consume more memory but is necessary for correct output
4432 when rendering to both the front and back buffers of a multisample or FSAA
4433 drawable. This option is necessary for correct operation of SoftImage XSI.
4434 Default: false (a single multisample buffer is shared between the front
4437 Option "NoPowerConnectorCheck" "boolean"
4439 The NVIDIA X driver will abort X server initialization if it detects that
4440 a GPU that requires an external power connector does not have an external
4441 power connector plugged in. This option can be used to bypass this test.
4442 Default: false (the power connector test is performed).
4444 Option "XvmcUsesTextures" "boolean"
4446 Forces XvMC to use the 3D engine for XvMCPutSurface requests rather than
4447 the video overlay. Default: false (video overlay is used when available).
4449 Option "AllowGLXWithComposite" "boolean"
4451 Enables GLX even when the Composite X extension is loaded. ENABLE AT YOUR
4452 OWN RISK. OpenGL applications will not display correctly in many
4453 circumstances with this setting enabled.
4455 This option is intended for use on X.Org X servers older than X11R6.9.0.
4456 On X11R6.9.0 or newer X servers, the NVIDIA OpenGL implementation
4457 interacts properly by default with the Composite X extension and this
4458 option should not be needed. However, on X11R6.9.0 or newer X servers,
4459 support for GLX with Composite can be disabled by setting this option to
4462 Default: false (GLX is disabled when Composite is enabled on X servers
4463 older than X11R6.9.0).
4465 Option "UseCompositeWrapper" "boolean"
4467 Enables the X server's "composite wrapper", which performs coordinate
4468 translations necessary for the Composite extension.
4470 Default: false (the NVIDIA X driver performs its own coordinate
4473 Option "AddARGBGLXVisuals" "boolean"
4475 Adds a 32-bit ARGB visual for each supported OpenGL configuration. This
4476 allows applications to use OpenGL to render with alpha transparency into
4477 32-bit windows and pixmaps. This option requires the Composite extension.
4478 Default: ARGB GLX visuals are enabled on X servers new enough to support
4479 them when the Composite extension is also enabled.
4481 Option "DisableGLXRootClipping" "boolean"
4483 If enabled, no clipping will be performed on rendering done by OpenGL in
4484 the root window. This option is deprecated. It is needed by older versions
4485 of OpenGL-based composite managers that draw the contents of redirected
4486 windows directly into the root window using OpenGL. Most OpenGL-based
4487 composite managers have been updated to support the Composite Overlay
4488 Window, a feature introduced in Xorg release 7.1. Using the Composite
4489 Overlay Window is the preferred method for performing OpenGL-based
4492 Option "DamageEvents" "boolean"
4494 Use OS-level events to efficiently notify X when a client has performed
4495 direct rendering to a window that needs to be composited. This will
4496 significantly improve performance and interactivity when using GLX
4497 applications with a composite manager running. It will also affect
4498 applications using GLX when rotation is enabled. This option is currently
4499 incompatible with SLI and Multi-GPU modes and will be disabled if either
4500 are used. Enabled by default.
4502 Option "ExactModeTimingsDVI" "boolean"
4504 Forces the initialization of the X server with the exact timings specified
4505 in the ModeLine. Default: false (for DVI devices, the X server initializes
4506 with the closest mode in the EDID list).
4508 Option "Coolbits" "integer"
4510 Enables various unsupported features, such as support for GPU clock
4511 manipulation in the NV-CONTROL X extension. This option accepts a bit mask
4512 of features to enable.
4514 When "1" (Bit 0) is set in the "Coolbits" option value, the
4515 nvidia-settings utility will contain a page labeled "Clock Frequencies"
4516 through which clock settings can be manipulated. "Coolbits" is only
4517 available on GeForce FX, Quadro FX and newer desktop GPUs. On GeForce FX
4518 and newer mobile GPUs, limited clock manipulation support is available
4519 when "1" is set in the "Coolbits" option value: clocks can be lowered
4520 relative to the default settings; overclocking is not supported due to the
4521 thermal constraints of notebook designs.
4523 WARNING: this may cause system damage and void warranties. This utility
4524 can run your computer system out of the manufacturer's design
4525 specifications, including, but not limited to: higher system voltages,
4526 above normal temperatures, excessive frequencies, and changes to BIOS that
4527 may corrupt the BIOS. Your computer's operating system may hang and result
4528 in data loss or corrupted images. Depending on the manufacturer of your
4529 computer system, the computer system, hardware and software warranties may
4530 be voided, and you may not receive any further manufacturer support.
4531 NVIDIA does not provide customer service support for the Coolbits option.
4532 It is for these reasons that absolutely no warranty or guarantee is either
4533 express or implied. Before enabling and using, you should determine the
4534 suitability of the utility for your intended use, and you shall assume all
4535 responsibility in connection therewith.
4537 When "2" (Bit 1) is set in the "Coolbits" option value, the NVIDIA driver
4538 will attempt to initialize SLI when using GPUs with different amounts of
4541 The default for this option is 0 (unsupported features are disabled).
4543 Option "MultiGPU" "string"
4545 This option controls the configuration of Multi-GPU rendering in supported
4549 -------------------------------- --------------------------------
4550 0, no, off, false, Single Use only a single GPU when
4552 1, yes, on, true, Auto Enable Multi-GPU and allow the
4553 driver to automatically select
4554 the appropriate rendering mode.
4555 AFR Enable Multi-GPU and use the
4556 Alternate Frame Rendering mode.
4557 SFR Enable Multi-GPU and use the
4558 Split Frame Rendering mode.
4559 AA Enable Multi-GPU and use
4560 antialiasing. Use this in
4561 conjunction with full scene
4562 antialiasing to improve visual
4566 Option "SLI" "string"
4568 This option controls the configuration of SLI rendering in supported
4572 -------------------------------- --------------------------------
4573 0, no, off, false, Single Use only a single GPU when
4575 1, yes, on, true, Auto Enable SLI and allow the driver
4576 to automatically select the
4577 appropriate rendering mode.
4578 AFR Enable SLI and use the Alternate
4579 Frame Rendering mode.
4580 SFR Enable SLI and use the Split
4581 Frame Rendering mode.
4582 AA Enable SLI and use SLI
4583 Antialiasing. Use this in
4584 conjunction with full scene
4585 antialiasing to improve visual
4587 AFRofAA Enable SLI and use SLI Alternate
4588 Frame Rendering of Antialiasing
4589 mode. Use this in conjunction
4590 with full scene antialiasing to
4591 improve visual quality. This
4592 option is only valid for SLI
4593 configurations with 4 GPUs.
4596 Option "TripleBuffer" "boolean"
4598 Enable or disable the use of triple buffering. If this option is enabled,
4599 OpenGL windows that sync to vblank and are double-buffered will be given a
4600 third buffer. This decreases the time an application stalls while waiting
4601 for vblank events, but increases latency slightly (delay between user
4602 input and displayed result).
4604 Option "DPI" "string"
4606 This option specifies the Dots Per Inch for the X screen; for example:
4608 Option "DPI" "75 x 85"
4610 will set the horizontal DPI to 75 and the vertical DPI to 85. By default,
4611 the X driver will compute the DPI of the X screen from the EDID of any
4612 connected display devices. See Appendix I for details. Default: string is
4615 Option "UseEdidDpi" "string"
4617 By default, the NVIDIA X driver computes the DPI of an X screen based on
4618 the physical size of the display device, as reported in the EDID, and the
4619 size in pixels of the first mode to be used on the display device. If
4620 multiple display devices are used by the X screen, then the NVIDIA X
4621 screen will choose which display device to use. This option can be used to
4622 specify which display device to use. The string argument can be a display
4623 device name, such as:
4625 Option "UseEdidDpi" "DFP-0"
4627 or the argument can be "FALSE" to disable use of EDID-based DPI
4630 Option "UseEdidDpi" "FALSE"
4632 See Appendix I for details. Default: string is NULL (the driver computes
4633 the DPI from the EDID of a display device and selects the display device).
4635 Option "ConstantDPI" "boolean"
4637 By default on X.Org 6.9 or newer X servers, the NVIDIA X driver recomputes
4638 the size in millimeters of the X screen whenever the size in pixels of the
4639 X screen is changed using XRandR, such that the DPI remains constant.
4641 This behavior can be disabled (which means that the size in millimeters
4642 will not change when the size in pixels of the X screen changes) by
4643 setting the "ConstantDPI" option to "FALSE"; e.g.,
4645 Option "ConstantDPI" "FALSE"
4647 ConstantDPI defaults to True.
4649 On X servers older than X.Org 6.9, the NVIDIA X driver cannot change the
4650 size in millimeters of the X screen. Therefore the DPI of the X screen
4651 will change when XRandR changes the size in pixels of the X screen. The
4652 driver will behave as if ConstantDPI was forced to FALSE.
4654 Option "CustomEDID" "string"
4656 This option forces the X driver to use the EDID specified in a file rather
4657 than the display's EDID. You may specify a semicolon separated list of
4658 display names and filename pairs. The display name is any of "CRT-0",
4659 "CRT-1", "DFP-0", "DFP-1", "TV-0", "TV-1". The file contains a raw EDID
4660 (e.g., a file generated by nvidia-settings).
4664 Option "CustomEDID" "CRT-0:/tmp/edid1.bin; DFP-0:/tmp/edid2.bin"
4666 will assign the EDID from the file /tmp/edid1.bin to the display device
4667 CRT-0, and the EDID from the file /tmp/edid2.bin to the display device
4668 DFP-0. Note that a display device name must always be specified even if
4669 only one EDID is specified.
4671 Option "ModeValidation" "string"
4673 This option provides fine-grained control over each stage of the mode
4674 validation pipeline, disabling individual mode validation checks. This
4675 option should only very rarely be used.
4677 The option string is a semicolon-separated list of comma-separated lists
4678 of mode validation arguments. Each list of mode validation arguments can
4679 optionally be prepended with a display device name.
4681 "<dpy-0>: <tok>, <tok>; <dpy-1>: <tok>, <tok>, <tok>; ..."
4686 o "AllowNon60HzDFPModes": some lower quality TMDS encoders are only
4687 rated to drive DFPs at 60Hz; the driver will determine when only 60Hz
4688 DFP modes are allowed. This argument disables this stage of the mode
4689 validation pipeline.
4691 o "NoMaxPClkCheck": each mode has a pixel clock; this pixel clock is
4692 validated against the maximum pixel clock of the hardware (for a DFP,
4693 this is the maximum pixel clock of the TMDS encoder, for a CRT, this
4694 is the maximum pixel clock of the DAC). This argument disables the
4695 maximum pixel clock checking stage of the mode validation pipeline.
4697 o "NoEdidMaxPClkCheck": a display device's EDID can specify the maximum
4698 pixel clock that the display device supports; a mode's pixel clock is
4699 validated against this pixel clock maximum. This argument disables
4700 this stage of the mode validation pipeline.
4702 o "AllowInterlacedModes": interlaced modes are not supported on all
4703 NVIDIA GPUs; the driver will discard interlaced modes on GPUs where
4704 interlaced modes are not supported; this argument disables this stage
4705 of the mode validation pipeline.
4707 o "NoMaxSizeCheck": each NVIDIA GPU has a maximum resolution that it
4708 can drive; this argument disables this stage of the mode validation
4711 o "NoHorizSyncCheck": a mode's horizontal sync is validated against the
4712 range of valid horizontal sync values; this argument disables this
4713 stage of the mode validation pipeline.
4715 o "NoVertRefreshCheck": a mode's vertical refresh rate is validated
4716 against the range of valid vertical refresh rate values; this
4717 argument disables this stage of the mode validation pipeline.
4719 o "NoWidthAlignmentCheck": the alignment of a mode's visible width is
4720 validated against the capabilities of the GPU; normally, a mode's
4721 visible width must be a multiple of 8. This argument disables this
4722 stage of the mode validation pipeline.
4724 o "NoDFPNativeResolutionCheck": when validating for a DFP, a mode's
4725 size is validated against the native resolution of the DFP; this
4726 argument disables this stage of the mode validation pipeline.
4728 o "NoVirtualSizeCheck": if the X configuration file requests a specific
4729 virtual screen size, a mode cannot be larger than that virtual size;
4730 this argument disables this stage of the mode validation pipeline.
4732 o "NoVesaModes": when constructing the mode pool for a display device,
4733 the X driver uses a built-in list of VESA modes as one of the mode
4734 sources; this argument disables use of these built-in VESA modes.
4736 o "NoEdidModes": when constructing the mode pool for a display device,
4737 the X driver uses any modes listed in the display device's EDID as
4738 one of the mode sources; this argument disables use of EDID-specified
4741 o "NoXServerModes": when constructing the mode pool for a display
4742 device, the X driver uses the built-in modes provided by the core
4743 XFree86/Xorg X server as one of the mode sources; this argument
4744 disables use of these modes. Note that this argument does not disable
4745 custom ModeLines specified in the X config file; see the
4746 "NoCustomModes" argument for that.
4748 o "NoCustomModes": when constructing the mode pool for a display
4749 device, the X driver uses custom ModeLines specified in the X config
4750 file (through the "Mode" or "ModeLine" entries in the Monitor
4751 Section) as one of the mode sources; this argument disables use of
4754 o "NoPredefinedModes": when constructing the mode pool for a display
4755 device, the X driver uses additional modes predefined by the NVIDIA X
4756 driver; this argument disables use of these modes.
4758 o "NoUserModes": additional modes can be added to the mode pool
4759 dynamically, using the NV-CONTROL X extension; this argument
4760 prohibits user-specified modes via the NV-CONTROL X extension.
4762 o "NoExtendedGpuCapabilitiesCheck": allow mode timings that may exceed
4763 the GPU's extended capability checks.
4765 o "ObeyEdidContradictions": an EDID may contradict itself by listing a
4766 mode as supported, but the mode may exceed an EDID-specified valid
4767 frequency range (HorizSync, VertRefresh, or maximum pixel clock).
4768 Normally, the NVIDIA X driver prints a warning in this scenario, but
4769 does not invalidate an EDID-specified mode just because it exceeds an
4770 EDID-specified valid frequency range. However, the
4771 "ObeyEdidContradictions" argument instructs the NVIDIA X driver to
4772 invalidate these modes.
4774 o "NoTotalSizeCheck": allow modes in which the invididual visible or
4775 sync pulse timings exceed the total raster size.
4777 o "DoubleScanPriority": on GPUs older than G80, doublescan modes are
4778 sorted before non-doublescan modes of the same resolution for
4779 purposes of modepool sorting; but on G80 and later GPUs, doublescan
4780 modes are sorted after non-doublescan modes of the same resolution.
4781 This token inverts that priority (i.e., doublescan modes will be
4782 sorted after on pre-G80 GPUs, and sorted before on G80 and later
4788 Option "ModeValidation" "NoMaxPClkCheck"
4790 disable the maximum pixel clock check when validating modes on all display
4793 Option "ModeValidation" "CRT-0: NoEdidModes, NoMaxPClkCheck; DFP-0:
4796 do not use EDID modes and do not perform the maximum pixel clock check on
4797 CRT-0, and do not use VESA modes on DFP-0.
4799 Option "UseEvents" "boolean"
4801 Enables the use of system events in some cases when the X driver is
4802 waiting for the hardware. The X driver can briefly spin through a tight
4803 loop when waiting for the hardware. With this option the X driver instead
4804 sets an event handler and waits for the hardware through the 'poll()'
4805 system call. Default: the use of the events is disabled.
4807 Option "FlatPanelProperties" "string"
4809 This option requests particular properties for all or a subset of the
4810 connected flat panels.
4812 The option string is a semicolon-separated list of comma-separated
4813 property=value pairs. Each list of property=value pairs can optionally be
4814 prepended with a flat panel name.
4816 "<DFP-0>: <property=value>, <property=value>; <DFP-1>:
4817 <property=value>; ..."
4820 Recognized properties:
4822 o "Scaling": controls the flat panel scaling mode; possible values are:
4823 'Default' (the driver will use whichever scaling state is current),
4824 'Native' (the driver will use the flat panel's scaler, if possible),
4825 'Scaled' (the driver will use the NVIDIA GPU's scaler, if possible),
4826 'Centered' (the driver will center the image, if possible), and
4827 'aspect-scaled' (the X driver will scale with the NVIDIA GPU's
4828 scaler, but keep the aspect ratio correct).
4830 o "Dithering": controls the flat panel dithering mode; possible values
4831 are: 'Default' (the driver will decide when to dither), 'Enabled'
4832 (the driver will always dither, if possible), and 'Disabled' (the
4833 driver will never dither).
4838 Option "FlatPanelProperties" "Scaling = Centered"
4840 set the flat panel scaling mode to centered on all flat panels.
4842 Option "FlatPanelProperties" "DFP-0: Scaling = Centered; DFP-1:
4843 Scaling = Scaled, Dithering = Enabled"
4845 set DFP-0's scaling mode to centered, set DFP-1's scaling mode to scaled
4846 and its dithering mode to enabled.
4848 Option "ProbeAllGpus" "boolean"
4850 When the NVIDIA X driver initializes, it probes all GPUs in the system,
4851 even if no X screens are configured on them. This is done so that the X
4852 driver can report information about all the system's GPUs through the
4853 NV-CONTROL X extension. This option can be set to FALSE to disable this
4854 behavior, such that only GPUs with X screens configured on them will be
4855 probed. Default: all GPUs in the system are probed.
4857 Option "DynamicTwinView" "boolean"
4859 Enable or disable support for dynamically configuring TwinView on this X
4860 screen. When DynamicTwinView is enabled (the default), the refresh rate of
4861 a mode (reported through XF86VidMode or XRandR) does not correctly report
4862 the refresh rate, but instead is a unique number such that each MetaMode
4863 has a different value. This is to guarantee that MetaModes can be uniquely
4864 identified by XRandR.
4866 When DynamicTwinView is disabled, the refresh rate reported through XRandR
4867 will be accurate, but NV-CONTROL clients such as nvidia-settings will not
4868 be able to dynamically manipulate the X screen's MetaModes. TwinView can
4869 still be configured from the X config file when DynamicTwinView is
4872 Default: DynamicTwinView is enabled.
4874 Option "IncludeImplicitMetaModes" "boolean"
4876 When the X server starts, a mode pool is created per display device,
4877 containing all the mode timings that the NVIDIA X driver determined to be
4878 valid for the display device. However, the only MetaModes that are made
4879 available to the X server are the ones explicitly requested in the X
4882 It is convenient for fullscreen applications to be able to change between
4883 the modes in the mode pool, even if a given target mode was not explicitly
4884 requested in the X configuration file.
4886 To facilitate this, the NVIDIA X driver will, if only one display device
4887 is in use when the X server starts, implicitly add MetaModes for all modes
4888 in the display device's mode pool. This makes all the modes in the mode
4889 pool available to full screen applications that use the XF86VidMode or
4890 XRandR X extensions.
4892 To prevent this behavior, and only add MetaModes that are explicitly
4893 requested in the X configuration file, set this option to FALSE.
4895 Default: IncludeImplicitMetaModes is enabled.
4897 Option "AllowIndirectPixmaps" "boolean"
4899 Some graphics cards have more video memory than can be mapped at once by
4900 the CPU (generally only 256 MB of video memory can be CPU-mapped). On
4901 graphics cards based on G80 and higher with such a memory configuration,
4902 this option allows the driver to place more pixmaps in video memory which
4903 will improve hardware rendering performance but will slow down software
4904 rendering. On some systems, up to 768 megabytes of virtual address space
4905 will be reserved in the X server for indirect pixmap access. This virtual
4906 memory does not consume any physical resources.
4908 Default: on (indirect pixmaps will be used, when available).
4910 Option "OnDemandVBlankInterrupts" "boolean"
4912 Normally, VBlank interrupts are generated on every vertical refresh of
4913 every display device connected to the GPU(s) installed in a given system.
4914 This experimental option enables on-demand VBlank control, allowing the
4915 driver to enable VBlank interrupt generation only when it is required.
4916 This can help conserve power.
4918 Default: off (on-demand VBlank control is disabled).
4921 ______________________________________________________________________________
4923 Appendix G. Display Device Names
4924 ______________________________________________________________________________
4926 A "display device" refers to some piece of hardware capable of displaying an
4927 image. There are three categories of display devices: analog displays (i.e.,
4928 CRTs), digital displays (i.e., digital flat panels (DFPs)), and televisions.
4929 Note that analog flat panels are considered the same as analog CRTs by the
4930 NVIDIA FreeBSD driver.
4932 A "display device name" is a string description that uniquely identifies a
4933 display device; it follows the format "<type>-<number>", for example: "CRT-0",
4934 "CRT-1", "DFP-0", or "TV-0". Note that the number indicates how the display
4935 device connector is wired on the graphics card, and has nothing to do with how
4936 many of that kind of display device are present. This means, for example, that
4937 you may have a "CRT-1", even if you do not have a "CRT-0". To determine which
4938 display devices are currently connected, you may check your X log file for a
4939 line similar to the following:
4941 (II) NVIDIA(0): Connected display device(s): CRT-0, DFP-0
4943 Display device names can be used in the MetaMode, HorizSync, and VertRefresh X
4944 config options to indicate which display device a setting should be applied
4947 Option "MetaModes" "CRT-0: 1600x1200, DFP-0: 1024x768"
4948 Option "HorizSync" "CRT-0: 50-110; DFP-0: 40-70"
4949 Option "VertRefresh" "CRT-0: 60-120; DFP-0: 60"
4951 Specifying the display device name in these options is not required; if
4952 display device names are not specified, then the driver attempts to infer
4953 which display device a setting applies to. In the case of MetaModes, for
4954 example, the first mode listed is applied to the "first" display device, and
4955 the second mode listed is applied to the "second" display device.
4956 Unfortunately, it is often unclear which display device is the "first" or
4957 "second". That is why specifying the display device name is preferable.
4959 When specifying display device names, you may also omit the number part of the
4960 name, though this is only useful if you only have one of that type of display
4961 device. For example, if you have one CRT and one DFP connected, you may
4962 reference them in the MetaMode string as follows:
4964 Option "MetaModes" "CRT: 1600x1200, DFP: 1024x768"
4967 ______________________________________________________________________________
4969 Appendix H. GLX Support
4970 ______________________________________________________________________________
4972 This release supports GLX 1.4.
4974 Additionally, the following GLX extensions are supported on appropriate GPUs:
4976 o GLX_EXT_visual_info
4978 o GLX_EXT_visual_rating
4984 o GLX_ARB_get_proc_address
4986 o GLX_SGI_video_sync
4988 o GLX_SGI_swap_control
4990 o GLX_ARB_multisample
4992 o GLX_NV_float_buffer
4994 o GLX_ARB_fbconfig_float
5000 o GLX_EXT_texture_from_pixmap
5002 For a description of these extensions, see the OpenGL extension registry at
5003 http://www.opengl.org/registry/
5005 Some of the above extensions exist as part of core GLX 1.4 functionality,
5006 however, they are also exported as extensions for backwards compatibility.
5008 ______________________________________________________________________________
5010 Appendix I. Dots Per Inch
5011 ______________________________________________________________________________
5013 DPI (Dots Per Inch), also known as PPI (Pixels Per Inch), is a property of an
5014 X screen that describes the physical size of pixels. Some X applications, such
5015 as xterm, can use the DPI of an X screen to determine how large (in pixels) to
5016 draw an object in order for that object to be displayed at the desired
5017 physical size on the display device.
5019 The DPI of an X screen is computed by dividing the size of the X screen in
5020 pixels by the size of the X screen in inches:
5022 DPI = SizeInPixels / SizeInInches
5024 Since the X screen stores its physical size in millimeters rather than inches
5025 (1 inch = 25.4 millimeters):
5027 DPI = (SizeInPixels * 25.4) / SizeInMillimeters
5029 The NVIDIA X driver reports the size of the X screen in pixels and in
5030 millimeters. On X.Org 6.9 or newer, when the XRandR extension resizes the X
5031 screen in pixels, the NVIDIA X driver computes a new size in millimeters for
5032 the X screen, to maintain a constant DPI (see the "Physical Size" column of
5033 the `xrandr -q` output as an example). This is done because a changing DPI can
5034 cause interaction problems for some applications. To disable this behavior,
5035 and instead keep the same millimeter size for the X screen (and therefore have
5036 a changing DPI), set the ConstantDPI option to FALSE (see Appendix F for
5039 You can query the DPI of your X screen by running:
5042 % xdpyinfo | grep -B1 dot
5045 which should generate output like this:
5048 dimensions: 1280x1024 pixels (382x302 millimeters)
5049 resolution: 85x86 dots per inch
5053 The NVIDIA X driver performs several steps during X screen initialization to
5054 determine the DPI of each X screen:
5057 o If the display device provides an EDID, and the EDID contains information
5058 about the physical size of the display device, that is used to compute
5059 the DPI, along with the size in pixels of the first mode to be used on
5060 the display device. If multiple display devices are used by this X
5061 screen, then the NVIDIA X screen will choose which display device to use.
5062 You can override this with the "UseEdidDpi" X configuration option: you
5063 can specify a particular display device to use; e.g.:
5065 Option "UseEdidDpi" "DFP-1"
5067 or disable EDID-computed DPI by setting this option to false:
5069 Option "UseEdidDpi" "FALSE"
5071 EDID-based DPI computation is enabled by default when an EDID is
5074 o If the "-dpi" commandline option to the X server is specified, that is
5075 used to set the DPI (see `X -h` for details). This will override the
5076 "UseEdidDpi" option.
5078 o If the "DPI" X configuration option is specified (see Appendix F for
5079 details), that will be used to set the DPI. This will override the
5080 "UseEdidDpi" option.
5082 o If none of the above are available, then the "DisplaySize" X config file
5083 Monitor section information will be used to determine the DPI, if
5084 provided; see the xorg.conf or XF86Config man pages for details.
5086 o If none of the above are available, the DPI defaults to 75x75.
5089 You can find how the NVIDIA X driver determined the DPI by looking in your X
5090 log file. There will be a line that looks something like the following:
5092 (--) NVIDIA(0): DPI set to (101, 101); computed from "UseEdidDpi" X config
5096 Note that the physical size of the X screen, as reported through `xdpyinfo` is
5097 computed based on the DPI and the size of the X screen in pixels.
5099 The DPI of an X screen can be confusing when TwinView is enabled: with
5100 TwinView, multiple display devices (possibly with different DPIs) display
5101 portions of the same X screen, yet DPI can only be advertised from the X
5102 server to the X application with X screen granularity. Solutions for this
5106 o Use separate X screens, rather than TwinView; see Chapter 12 for details.
5108 o Experiment with different DPI settings to find a DPI that is suitable for
5109 both display devices.
5112 ______________________________________________________________________________
5114 Appendix J. XvMC Support
5115 ______________________________________________________________________________
5117 This release includes support for the XVideo Motion Compensation (XvMC)
5118 version 1.0 API on GeForce 5 series, GeForce 6 series and GeForce 7 series
5119 addin cards, as well as motherboard chipsets with integrated graphics that
5120 have PureVideo support. There is a static library, "libXvMCNVIDIA.a", and a
5121 dynamic one, "libXvMCNVIDIA_dynamic.so", which is suitable for dlopening.
5122 XvMC's "IDCT" and "motion-compensation" levels of acceleration, AI44 and IA44
5123 subpictures, and 4:2:0 Surfaces up to 2032x2032 are supported.
5125 libXvMCNVIDIA observes the XVMC_DEBUG environment variable and will provide
5126 some debug output to stderr when set to an appropriate integer value. '0'
5127 disables debug output. '1' enables debug output for failure conditions. '2' or
5128 higher enables output of warning messages.