Linux - Programming modes

Answer ID 178
Published 11/30/2004 10:05 AM
Updated 02/25/2008 10:48 AM

Programming modes


The NVIDIA Accelerated Linux Driver Set supports all standard VGA and
VESA modes, as well as most user-written custom mode lines; double-scan
modes are supported on all hardware.  Interlaced modes are supported on
all GeForce FX/Quadro FX and newer GPUs, and certain older GPUs; the X
log file will contain a message "Interlaced video modes are supported
on this GPU" if interlaced modes are supported.

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

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

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

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


DEPTH, BITS PER PIXEL, AND PITCH

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

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

Lastly, the "pitch" is how many bytes in the linear frame buffer there are
between one pixel's data, and the data of the pixel immediately below.
You can think of this as the horizontal resolution multiplied by the
bytes per pixel (bits per pixel divided by 8).  In practice, the pitch may
be more than this product due to alignment constraints.


MAXIMUM RESOLUTIONS

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


USEFUL FORMULAS

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

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

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

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

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

RR = PCLK / (HFL * VFL)

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

PCLK = RR * HFL * VFL

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

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

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


HOW MODES ARE VALIDATED

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

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

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

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

  o All modes are also tested to confirm that they fit within the
 hardware's memory bandwidth constraints.  This test can be disabled
 with the NoBandWidthTest X config file option.

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

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


ADDITIONAL MODE CONSTRAINTS

Below is a list of additional constraints on a mode's parameters that
must be met.  In some cases these are specific to particular chips.

  o The horizontal resolution (HR) must be a multiple of 8 and be less
 than or equal to the value in the table below.
  o The horizontal blanking width (the maximum of the horizontal frame
 length and the horizontal sync end minus the minimum of the horizontal
 resolution and the horizontal sync start (max(HFL,HSE) - min(HR,HSS))
 must be a multiple of 8 and be less than or equal to the value in
 the table below.
  o The horizontal sync start (HSS) must be a multiple of 8 and be less
 than or equal to the value in the table below.
  o The horizontal sync width (the horizontal sync end minus the
 horizontal sync start (HSE - HSS)) must be a multiple of 8 and be
 less than or equal to the value in the table below.
  o The horizontal frame length (HFL) must be a multiple of 8, must be
 greater than or equal to 40, and must be less than or equal to the
 value in the table below.
  o The vertical resolution (VR) must be less than or equal to the
 value in the table below.
  o The vertical blanking width (the maximum of the vertical frame length
 and the vertical sync end minus the minimum of the vertical resolution
 and the vertical sync start (max(VFL,VSE) - min(VR,VSS)) must be
 less than or equal to the value in the table below.
  o The vertical sync start (VSS) must be less than or equal to the
 value in the table below.
  o The vertical sync width (the vertical sync end minus the vertical sync
 start (VSE - VSS)) must be less than or equal to the value in the
 table below.
  o The vertical frame length (VFL) must be greater than or equal to 2 and
 less than or equal to the value in the table below.

    Maximum DAC Values
    ------------------

  | GeForce/TNT   Geforce2 & 3   Geforce4 or newer
 ______|_______________________________________________
  |
 HR    | 40964096 8192
 HBW   | 10161016 2040
 HSS   | 40884088 8224
 HSW   | 256 256  512
 HFL   | 41284128 8224
 VR    | 20484096 8192
 VBW   | 128 128  256
 VSS   | 20474095 8192
 VSW   | 16  16   16
 VFL   | 20494097 8192


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

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

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


ENSURING IDENTICAL MODETIMINGS

Some functionality, such as Active Stereo with TwinView, requires
control over exactly what mode timings are used.  There are several
ways to accomplish that:

 o If you only want to make sure that both display devices use
   the same modes, you only need to make sure that both display
   devices use the same HorizSync and VertRefresh values when
   performing mode validation; this would be done by making sure the
   HorizSync and SecondMonitorHorizSync match, and that the VertRefresh
   and the SecondMonitorVertRefresh match.

 o A more explicit approach is to specify the modeline you wish
   to use (using one of the modeline generators available),
   and using a unique name.  For example, if you wanted to use
   1024x768 at 120 Hz on each monitor in TwinView with active
   stereo, you might add something like:

# 1024x768 @ 120.00 Hz (GTF) hsync: 98.76 kHz; pclk: 139.05 MHz
Modeline "1024x768_120"  139.05  1024 1104 1216 1408  768 769 772 823  -HSync +Vsync

   In the monitor section of your X config file, and then in the
   Screen section of your X config file, specify a MetaMode like this:

Option "MetaModes" "1024x768_120, 1024x768_120"

SEE ALSO:

 An XFree86 modeline generator, conforming to the GTF Standard is
 available here:

http://gtf.sourceforge.net/

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

Was this answer helpful?
Your rating has been submitted, please tell us how we can make this answer more useful.

LIVE CHAT

Chat online with one of our support agents

CHAT NOW

ASK US A QUESTION

Contact Support for assistance

CONTACT US