I found this on the Nvidia web site, I think it may help you out.
(app-l) APPENDIX L: PROGRAMMING MODES
__________________________________________________________________________
The NVIDIA Accelerated Linux Driver Set supports all standard VGA and
VESA
modes, as well as most user-written custom mode lines; double-scan modes
are supported on all hardware, and interlaced modes are supported on:
GeForce 256, GeForce DDR, Quadro, GeForce2 GTS/GeForce2 Pro, GeForce2
Ti,
GeForce2 Ultra, Quadro2 Pro, and all TNT products.
In general, your display device (monitor/flat panel/television) will be
a greater constraint on what modes you can use than either your NVIDIA
GPU-based video board or the NVIDIA Accelerated Linux Driver Set.
To request one or more standard modes for use in X, you can simply add a
"Modes" line such as:
Modes "1600x1200" "1024x768" "640x480"
in the appropriate Display subsection of your XF86Config file
(please see
the XF86Config(4/5) man page for details). The following
documentation
is primarily of interest if you compose your own custom mode
lines,
experiment with xvidtune(1), or are just interested in learning
more.
Please note that this is neither an explanation nor a guide to
the fine
art of crafting custom mode lines for XFree86. We leave that,
rather,
to documents such as the XFree86 Video Timings HOWTO (which can
be found
at www.linuxdoc.org).
DEPTH, BITS PER PIXEL, AND PITCH
While not directly a concern when programming modes, the bits
used per
pixel is an issue when considering the maximum programmable
resolution;
for this reason, it is worthwhile to address the confusion
surrounding
the terms "depth" and "bits per pixel". Depth is how many bits
of
data are stored per pixel. Supported depths are 8, 15, 16, and
24.
Most video hardware, however, stores pixel data in sizes of 8,
16, or
32 bits; this is the amount of memory allocated per pixel. When
you
specify your depth, X selects the bits per pixel (bpp) size in
which to
store the data. Below is a table of what bpp is used for each
possible
depth:
depth bpp
===== =====
8 8
15 16
16 16
24 32
Lastly, the
"pitch" is
how many
bytes in
the linear
frame
buffer
there are
between one
pixel's
data, and
the data of
the pixel
immediately
below.
You can
think of
this as the
horizontal
resolution
multiplied
by the
bytes per
pixel (bits
per pixel
divided by
8). In
practice,
the pitch
may
be more
than this
product
because
video
hardware
often has
requirements
that the
pitch be a
multiple of
some value.
MAXIMUM
RESOLUTIONS
The NVIDIA
Accelerated
Linux
Driver Set
and NVIDIA
GPU-based
video
boards
support
resolutions
up to
2048x1536,
though the
maximum
resolution
your system
can support
is also
limited by
the amount
of video
memory
(see USEFUL
FORMULAS
for
details)
and the
maximum
supported
resolution
of your
display
device
(monitor/flat
panel/television).
Also note
that
while use
of a video
overlay
does not
limit the
maximum
resolution
or
refresh
rate, video
memory
bandwidth
used by a
programmed
mode does
effect the
overlay
quality.
USEFUL
FORMULAS
The maximum
resolution
is a
function
both of the
amount of
video
memory
and the
bits per
pixel you
elect to
use:
HR
* VR
* *
* (bpp/8)
* =
* Video
* Memory
* Used
In
other
words,
the
amount
of
video
memory
used
is
equal
to
the
horizontal
resolution
(HR)
multiplied
by
the
vertical
resolution
(VR)
multiplied
by
the
bytes
per
pixel
(bits
per
pixel
divided
by
eight).
Technically,
the
video
memory
used
is
actually
the
pitch
times
the
vertical
resolution,
and
the
pitch
may
be
slightly
greater
than
(HR
* (bpp/8))
* to
* accommodate
hardware
requirements
that
the
pitch
be
a
multiple
of
some
value.
Please
note
that
this
is
just
memory
usage
for
the
frame
buffer;
video
memory
is
also
used
by
other
things
such
as
OpenGL
or
pixmap
caching.
Another
important
relationship
is
that
between
the
resolution,
the
pixel
clock
(aka
dot
clock)
and
the
vertical
refresh
rate:
RR
=
PCLK
/
(HFL
* VFL)
In
other
words,
the
refresh
rate
(RR)
is
equal
to
the
pixel
clock
(PCLK)
divided
by
the
total
number
of
pixels:
the
horizontal
frame
length
(HFL)
multiplied
by
the
vertical
frame
length
(VFL)
(note
that
these
are
the
frame
lengths,
and
not
just
the
visible
resolutions).
As
described
in
the
XFree86
Video
Timings
HOWTO,
the
above
formula
can
be
rewritten
as:
PCLK
=
RR
* HFL
* *
* VFL
Given
a
maximum
pixel
clock,
you
can
adjust
the
RR,
HFL
and
VFL
as
desired,
as
long
as
the
product
of
the
three
is
consistent.
The
pixel
clock
is
reported
in
the
log
file
when
you
run
X
with
verbose
logging:
`startx
--
-logverbose
5`.
Your
XFree86.0.log
should
contain
several
lines
like:
(--)
NVIDIA(0):
Display
Device
0:
maximum
pixel
clock
at
8
bpp:
350
MHz
(--)
NVIDIA(0):
Display
Device
0:
maximum
pixel
clock
at
16
bpp:
350
MHz
(--)
NVIDIA(0):
Display
Device
0:
maximum
pixel
clock
at
32
bpp:
300
MHz
which
indicate
the
maximum
pixel
clock
at
each
bit
per
pixel
size.
HOW
MODES
ARE
VALIDATED
During
the
PreInit
phase
of
the
X
server,
the
NVIDIA
X
driver
validates
all
requested
modes
by
doing
the
following:
o
Take
the
intersection
of
the
HorizSync
and
VertRefresh
ranges
given
by
the
user
in
the
XF86Config
with
the
ranges
reported
by
the
monitor
in
the
EDID
(Extended
Display
Identification
Data);
this
behavior
can
be
disabled
by
using
the
"IgnoreEDID"
option
in
which
case
the
X
driver
will
blindly
accept
the
HorizSync
and
VertRefresh
ranges
given
by
the
user.
o
Call
the
xf86ValidateModes()
helper
function,
which
finds
modes
with
the
names
the
user
specified
in
the
XF86Config
file,
pruning
out
modes
with
invalid
horizontal
sync
frequencies
or
vertical
refresh
rates,
pixel
clocks
larger
than
the
maximum
pixel
clock
for
the
video
card,
or
resolutions
larger
than
the
virtual
screen
size
(if
a
virtual
screen
size
was
specified
in
the
XF86Config
file).
Several
other
constraints
are
applied;
see
xc/programs/Xserver/hw/xfree86/common/xf86Mode.c:xf86ValidateModes().
o
All
modes
returned
from
xf86ValidateModes()
are
then
examined
to
make
sure
their
resolutions
are
not
larger
than
the
largest
mode
reported
by
the
monitor's
EDID
(this
can
be
disabled
with
the
"IgnoreEDID"
option.
If
the
display
is
a
TV,
each
mode
is
checked
to
make
sure
it
has
a
resolution
that
is
supported
by
the
TV
encoder
(usually
only
800x600
and
640x480
are
supported
by
the
encoder).
o
All
remaining
modes
are
then
checked
to
make
sure
they
pass
the
constraints
described
below
in
ADDITIONAL
MODE
CONSTRAINTS.
The
last
two
steps
are
also
done
when
each
mode
is
programmed,
to
catch
potentially
invalid
modes
submitted
by
the
XF86VidModeExtension
(eg
xvidtune(1)).
For
TwinView,
the
above
validation
is
done
for
the
modes
requested
for
each
display
device.
ADDITIONAL
MODE
CONSTRAINTS
Below
is
a
list
of
additional
constraints
on
a
mode's
parameters
that
must
be
met.
o
The
horizontal
resolution
(HR)
must
be
a
multiple
of
4
and
be
less
than
or
equal
to
2048.
o
The
horizontal
blanking
width
(the
maximum
of
the
horizontal
frame
length
and
the
horizontal
sync
end
minus
the
minimum
of
the
horizontal
resolution
and
the
horizontal
sync
start
(max(HFL,HSE)
- min(HR,HSS))
must
be
a
multiple
of
4
and
be
less
than
or
equal
to
1024.
o
The
horizontal
sync
start
(HSS)
must
be
a
multiple
of
4
and
be
less
than
or
equal
to
4088.
o
The
horizontal
sync
width
(the
horizontal
sync
end
minus
the
horizontal
sync
start
(HSE
- HSS))
must
be
a
multiple
of
4
and
be
less
than
or
equal
to
256.
o
The
horizontal
frame
length
(HFL)
must
be
a
multiple
of
4
and
be
less
than
or
equal
to
4128
and
be
greater
than
or
equal
to
40.
o
The
vertical
resolution
(VR)
must
be
less
than
or
equal
to
2048.
o
The
vertical
blanking
width
(the
maximum
of
the
vertical
frame
length
and
the
vertical
sync
end
minus
the
minimum
of
the
vertical
resolution
and
the
vertical
sync
start
(max(VFL,VSE)
- min(VR,VSS))
must
be
less
than
or
equal
to
128.
o
The
vertical
sync
start
(VSS)
must
be
less
than
or
equal
to
2047.
o
The
vertical
sync
width
(the
vertical
sync
end
minus
the
vertical
sync
start
(VSE
- VSS))
must
be
less
than
or
equal
to
16.
o
The
vertical
frame
length
(VFL)
must
be
less
than
or
equal
to
2049
and
be
greater
than
or
equal
to
2.
Here
is
an
example
mode
line
demonstrating
the
use
of
each
abbreviation
used
above:
# Custom
# Mode
# line
# for
# the
# SGI
# 1600SW
# Flatpanel
# name
# PCLK
# HR
# HSS
# HSE
# HFL
# VR
# VSS
# VSE
# VFL
Modeline
"sgi1600x1024"
106.9
1600
1632
1656
1672
1024
1027
1030
1067
SEE
ALSO:
An
XFree86
modeline
generator,
conforming
to
the
GTF
Standard
has
been
posted
to
the
XFree86
Xpert
mailing
list:
http://www.xfree86.org/pipermail/xpert/2001-October/012070.html
For
additional
modeline
generators,
try
searching
for
"modeline"
on
freshmeat.net.
--
The archive is at https://www.libranetlinux.com/archive.html
To unsubscribe, send email to [email protected]
with a subject of UNSUBSCRIBE.