mirror of https://github.com/tLDP/LDP
1538 lines
67 KiB
Plaintext
1538 lines
67 KiB
Plaintext
<!-- This is the XFree86 Video Timings HOWTO, SGML source -- >
|
|
<!-- Eric S. Raymond, esr@snark.thyrsus.com -- >
|
|
|
|
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<title>XFree86 Video Timings HOWTO
|
|
<author>Eric S. Raymond <esr@thyrsus.com>
|
|
<date>Version 4.4, 13 Mar 2000
|
|
|
|
<abstract>
|
|
How to compose a mode line for your card/monitor combination under
|
|
<idx>XFree86</idx>. The XFree86 distribution now includes good
|
|
facilities for configuring most standard combinations; this document
|
|
is mainly useful if you are tuning a custom mode line for a
|
|
high-performance monitor or very unusual hardware. It may also help
|
|
you in using kvideogen to generate mode lines, or xvidtune to tweak a
|
|
standard mode that is not quite right for your monitor.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>Disclaimer
|
|
<p>
|
|
|
|
You use the material herein SOLELY AT YOUR OWN RISK. It is possible
|
|
to harm both your monitor and yourself when driving it outside the
|
|
manufacturer's specs. Read <ref id="overd" name="Overdriving Your
|
|
Monitor"> for detailed cautions. Any damage to you or your monitor
|
|
caused by overdriving it is your problem.
|
|
|
|
The most up-to-date version of this HOWTO can be found at the <url
|
|
url="http://metalab.unc.edu/LDP"
|
|
name="Linux Documentation Project"> web page.
|
|
|
|
Please direct comments, criticism, and suggestions for improvement to
|
|
<htmlurl url="mailto:esr@thyrsus.com" name="esr@snark.thyrsus.com">. Please do
|
|
<em>not</em> send email pleading for a magic solution to your
|
|
special monitor problem, as doing so will only burn up my time and
|
|
frustrate you -- everything I know about the subject is already in
|
|
here.
|
|
|
|
<sect>Introduction<label id="intro">
|
|
<p>
|
|
|
|
The XFree86 server allows users to configure their video subsystem and thus
|
|
encourages best use of existing hardware. This document is intended to help
|
|
you learn how to generate your own timing numbers to make optimum use of your
|
|
video card and monitor.
|
|
|
|
We'll present a method for getting something that works, and then show you how
|
|
you can experiment starting from that base to develop settings that optimize
|
|
for your taste.
|
|
|
|
If you already have a mode that almost works (in particular, if one of
|
|
predefined VESA modes gives you a stable display but one that's
|
|
displaced right or left, or too small, or too large) you can go
|
|
straight to the section on <ref id="fixes" name="Fixing Problems with the
|
|
Image">. This will enlighten you on ways to tweak the timing
|
|
numbers to achieve particular effects.
|
|
|
|
Don't assume that you need to get all the way into mode tuning just
|
|
because your X comes up with a scrambled display first time after
|
|
installation; it may be that most of the factory mode lines are OK and
|
|
you just happened to default to one that doesn't fit your
|
|
hardware. Instead, cycle through all your installed modes with
|
|
CTRL-ALT-KP+. If some of the modes look OK, try commenting out all but
|
|
a 640x480 and check that that mode works. If it does then uncomment a
|
|
couple of other modes, e.g. an 800x600 and a 1024x768 at a frequency
|
|
that your monitor should be able to handle.
|
|
|
|
More help is on the way. Many driver modules in the just-released
|
|
XFree86 4.0 support DDC, the VESA Display Data Channel facility. When
|
|
DDC is enabled, the monitor actually tells XFree86 what modelines
|
|
it can support. So with 4.0 and any recently-manufactured monitor
|
|
you are likely not to have to do any configuration at all.
|
|
|
|
<sect>Tools for Automatic Computation
|
|
<p>
|
|
If you have a relatively new monitor (1996 or later) that supports the
|
|
PnP specification, there is a chance that you use the read-edid
|
|
program to ask the monitor for its stastics and compute a mode line
|
|
for you. See <url url="http://altern.org/vii/programs/linux/read-edid/">.
|
|
|
|
Starting with XFree86 3.2, XFree86 provides an <bf>XF86Setup</bf>(1)
|
|
program that makes it easy to generate a working monitor mode
|
|
interactively, without messing with video timing number directly. So
|
|
you shouldn't actually need to calculate a base monitor mode in most
|
|
cases. Unfortunately, <bf>XF86Setup</bf>(1) has some limitations; it
|
|
only knows about standard video modes up to 1280x1024. If you have a
|
|
very high-performance monitor capable of 1600x1200 or more you will
|
|
still have to compute your base monitor mode yourself.
|
|
|
|
There is a KDE tool called <url
|
|
url="http://without.netpedia.net/kvideogen/" name="KVideoGen"> that
|
|
computes modelines from basic monitor and card statistics. I've
|
|
experimented with generating modelines from it, but haven't tried them
|
|
live. Note that its horizontal and vertical `refresh rate' parameters
|
|
are the same as the sync frequencies HSF and VSF we describe below. The
|
|
`horizontal sync pulse' number seems to be a sync pulse width in
|
|
microseconds, HSP (with the tool assuming fixed `front porch' HGT1 and
|
|
`back porch' HGT2 values). If you don't know the `horizontal sync
|
|
pulse' number it's safe to use the default.<P>
|
|
|
|
Recent versions of XFree86 provide a tool called <bf>xvidtune</bf>(1)
|
|
which you will probably find quite useful for testing and tuning
|
|
monitor modes. It begins with a gruesome warning about the possible
|
|
consequences of mistakes with it. If you pay careful attention to
|
|
this document and learn what is behind the pretty numbers in
|
|
xvidtune's boxes, you will become able to use xvidtune effectively and
|
|
with confidence.
|
|
|
|
If you have <bf>xvidtune</bf>(1), you'll be able to test new modes on the fly,
|
|
without modifying your X configuration files or even rebooting your X server.
|
|
Otherwise, XFree86 allows you to hot-key between different modes defined in
|
|
Xconfig (see XFree86.man for details). Use this capabilty to save
|
|
yourself hassles! When you want to test a new mode, give it a unique
|
|
mode label and add it to the <EM>end</EM> of your hot-key list. Leave a
|
|
known-good mode as the default to fall back on if the test mode
|
|
doesn't work.
|
|
|
|
Towards the end of this document, we include a `modeplot' script that
|
|
you can use to produce an analog graph of available modes. This is
|
|
not directly helpful for generating modelines, but it may help you
|
|
better understand the relationships that define them.
|
|
|
|
<sect>How Video Displays Work<label id="video">
|
|
<p>
|
|
Knowing how the <idx>display</idx> works is essential to understanding
|
|
what numbers to put in the various fields in the file Xconfig. Those
|
|
values are used in the lowest levels of controlling the display by the
|
|
XFree86 server.
|
|
|
|
The display generates a picture from what you could consider to be a
|
|
series of raster dots. The dots are arranged from left to right to form
|
|
lines. The lines are arranged from top to bottom to form the picture.
|
|
The dots emit light when they are struck by the electron beams inside
|
|
the display, one for each primary color. To make the beams strike
|
|
each dot for an equal amount of time, the beams are swept across the
|
|
display in a constant pattern, called a raster.
|
|
|
|
We say "what you could consider to be a series of dots" because these
|
|
raster dots don't actually correspond to physical phosphor dots. The
|
|
physical phosphor dots are much smaller than raster dots -- they have
|
|
to be, otherwise the display would suffer from severe
|
|
moiré-pattern effects. The raster dots are really samples of
|
|
the analog driver signal, and display as a grid of dots only because
|
|
the peaks and valleys in the signal are quite regularly and finely
|
|
spaced.
|
|
|
|
The pattern starts at the top left of the screen, goes across the
|
|
screen to the right in a straight line, moving ever so slightly
|
|
"downhill" (the downhill slope is too small to be perceptible). Then
|
|
the beams are swept back to the left side of the display, starting at
|
|
a new line. The new line is swept from left to right just as the
|
|
first line was. This pattern is repeated until the bottom line on the
|
|
display has been swept. Then the beams are moved from the bottom
|
|
right corner of the display (sweeping back and forth a few times) to
|
|
the top left corner, and the pattern is started over again.
|
|
|
|
There is one variation of this scheme known as <idx>interlacing</idx>:
|
|
here only every second line is swept during one half-frame and the
|
|
others are filled in during a second half-frame.
|
|
|
|
Starting the beams at the top left of the display is called the
|
|
beginning of a frame. The frame ends when the beams reach the the top
|
|
left corner again as they come from the bottom right corner of the
|
|
display. A frame is made up of all of the lines the beams traced from
|
|
the top of the display to the bottom.
|
|
|
|
If the electron beams were on all of the time they were sweeping
|
|
through the frame, all of the dots on the display would be
|
|
illuminated. There would be no black border around the edges of the
|
|
display. At the edges of the display the picture would become
|
|
distorted because the beams are hard to control there. To reduce the
|
|
distortion, the dots around the edges of the display are not
|
|
illuminated by the beams (because they're turned off) even though the
|
|
beams, if they were turned on, would be pointing at them. The
|
|
viewable area of the display is reduced this way.
|
|
|
|
Another important thing to understand is what becomes of the beams
|
|
when no spot is being painted on the visible area. The time the beams
|
|
would have been illuminating the side borders of the display is used
|
|
for sweeping the beams back from the right edge to the left. The time
|
|
the beams would have been illuminating the top and bottom borders of
|
|
the display is used for moving the beams from the bottom-right corner
|
|
of the display to the top-left corner.
|
|
|
|
The adapter card generates the signals which cause the display to turn
|
|
on the electron beams (according to the desired color) at each dot to
|
|
generate a picture. The card also controls when the display moves the
|
|
beams from the right side back to the left by generating a signal
|
|
called the horizontal sync (for synchronization) pulse. One
|
|
horizontal sync pulse occurs at the end of every line. The adapter
|
|
also generates a vertical sync pulse which signals the display to move
|
|
the beams to the top-left corner of the display. A vertical sync
|
|
pulse is generated near the end of every frame.
|
|
|
|
The display requires that there be short time periods both before and
|
|
after the horizontal and vertical sync pulses so that the position of
|
|
the electron beams can stabilize. If the beams can't stabilize, the
|
|
picture will not be steady.
|
|
|
|
For more information, see <url
|
|
url="http://fribble.cie.rpi.edu/~repairfaq/REPAIR/F_deflfaq.html"
|
|
name="TV and Monitor Deflection Systems">.
|
|
|
|
In a later section, we'll come back to these basics with definitions,
|
|
formulas and examples to help you use them.
|
|
|
|
<sect>Basic Things to Know about your Display and Adapter<label id="basic">
|
|
<p>
|
|
|
|
There are some fundamental things you need to know before hacking an Xconfig
|
|
entry. These are:
|
|
|
|
<itemize>
|
|
<item>your monitor's horizontal and vertical sync frequency options
|
|
<item>your monitor's bandwidth
|
|
<item>your video adapter's driving clock frequencies, or "dot clocks"
|
|
</itemize>
|
|
|
|
<sect1>The monitor sync frequencies
|
|
<p>
|
|
The <idx>horizontal sync frequency</idx> is just the number of times
|
|
per second the monitor can write a horizontal scan line; it is the
|
|
single most important statistic about your monitor. The vertical sync
|
|
frequency is the number of times per second the monitor can traverse
|
|
its beam vertically.
|
|
|
|
Sync frequencies are usually listed on the specifications page of your
|
|
monitor manual. The <idx>vertical sync frequency</idx> number is
|
|
typically calibrated in Hz (cycles per second), the horizontal one in
|
|
KHz (kilocycles per second). The usual ranges are between 50 and
|
|
150Hz vertical, and between 31 and 135KHz horizontal.
|
|
|
|
If you have a multisync monitor, these frequencies will be given as ranges.
|
|
Some monitors, especially lower-end ones, have multiple fixed frequencies.
|
|
These can be configured too, but your options will be severely limited by the
|
|
built-in monitor characteristics. Choose the highest frequency pair for best
|
|
resolution. And be careful --- trying to clock a fixed-frequency monitor at a
|
|
higher speed than it's designed for can easily damage it.
|
|
|
|
Earlier versions of this guide were pretty cavalier about overdriving
|
|
multisync monitors, pushing them past their nominal highest vertical
|
|
sync frequency in order to get better performance. We have since had more
|
|
reasons pointed out to us for caution on this score; we'll cover those under
|
|
<ref id="overd" name="Overdriving Your Monitor"> below.
|
|
|
|
<sect1>The monitor's video bandwidth
|
|
<p>
|
|
Your monitor's video bandwidth should be included on the manual's spec page.
|
|
If it's not, look at the monitor's higest rated resolution. As a rule of
|
|
thumb, here's how to translate these into bandwidth estimates (and thus into
|
|
rough upper bounds for the dot clock you can use):
|
|
|
|
<tscreen><verb>
|
|
640x480 25
|
|
800x600 36
|
|
1024x768 65
|
|
1024x768 interlaced 45
|
|
1280x1024 110
|
|
1600x1200 185
|
|
</verb></tscreen>
|
|
|
|
BTW, there's nothing magic about this table; these numbers are just
|
|
the lowest dot clocks per resolution in the standard XFree86 Modes
|
|
database (except for the last, which I extrapolated). The bandwidth
|
|
of your monitor may actually be higher than the minimum needed for its
|
|
top resolution, so don't be afraid to try a dot clock a few MHz
|
|
higher.
|
|
|
|
Also note that bandwidth is seldom an issue for dot clocks under 65MHz
|
|
or so. With an SVGA card and most hi-res monitors, you can't get
|
|
anywhere near the limit of your monitor's video bandwidth. The
|
|
following are examples:
|
|
|
|
<tscreen><verb>
|
|
Brand Video Bandwidth
|
|
---------- ---------------
|
|
NEC 4D 75Mhz
|
|
Nano 907a 50Mhz
|
|
Nano 9080i 60Mhz
|
|
Mitsubishi HL6615 110Mhz
|
|
Mitsubishi Diamond Scan 100Mhz
|
|
IDEK MF-5117 65Mhz
|
|
IOCOMM Thinksync-17 CM-7126 136Mhz
|
|
HP D1188A 100Mhz
|
|
Philips SC-17AS 110Mhz
|
|
Swan SW617 85Mhz
|
|
Viewsonic 21PS 185Mhz
|
|
PanaSync/Pro P21 220Mhz
|
|
</verb></tscreen>
|
|
|
|
Even low-end monitors usually aren't terribly bandwidth-constrained for their
|
|
rated resolutions. The NEC Multisync II makes a good example --- it can't
|
|
even display 800x600 per its spec. It can only display 800x560. For such low
|
|
resolutions you don't need high dot clocks or a lot of bandwidth; probably the
|
|
best you can do is 32Mhz or 36Mhz, both of them are still not too far from the
|
|
monitor's rated video bandwidth of 30Mhz.
|
|
|
|
At these two driving frequencies, your screen image may not be as sharp as it
|
|
should be, but definitely of tolerable quality. Of course it would be nicer if
|
|
NEC Multisync II had a video bandwidth higher than, say, 36Mhz. But this is
|
|
not critical for common tasks like text editing, as long as the difference is
|
|
not so significant as to cause severe image distortion (your eyes would tell
|
|
you right away if this were so).
|
|
|
|
<sect1>The card's dot clock
|
|
<p>
|
|
Your video adapter manual's spec page will usually give you the card's
|
|
maximum <idx>dot clock</idx> (that is, the total number of pixels per second
|
|
it can write to the screen).
|
|
|
|
If you don't have this information, the X server will get it for you.
|
|
Recent versions of the X servers all support a --probeonly option that
|
|
prints out this information and exits without actually starting up X
|
|
or changing the video mode.
|
|
|
|
If you don't have -probeonly, don't depair. Even if your X locks up
|
|
your monitor, it will emit a line of clock and other info to standard
|
|
error. If you redirect this to a file, it should be saved even if you
|
|
have to reboot to get your console back.
|
|
|
|
The probe result or startup message should look something like one of
|
|
the following examples:
|
|
|
|
If you're using XFree86:
|
|
|
|
<verb>
|
|
Xconfig: /usr/X11R6/lib/X11/Xconfig
|
|
(**) stands for supplied, (--) stands for probed/default values
|
|
(**) Mouse: type: MouseMan, device: /dev/ttyS1, baudrate: 9600
|
|
Warning: The directory "/usr/andrew/X11fonts" does not exist.
|
|
Entry deleted from font path.
|
|
(**) FontPath set to "/usr/lib/X11/fonts/misc/,/usr/lib/X11/fonts/75dpi/"
|
|
(--) S3: card type: 386/486 localbus
|
|
(--) S3: chipset: 924
|
|
---
|
|
Chipset -- this is the exact chip type; an early mask of the 86C911
|
|
|
|
(--) S3: chipset driver: s3_generic
|
|
(--) S3: videoram: 1024k
|
|
-----
|
|
Size of on-board frame-buffer RAM
|
|
|
|
(**) S3: clocks: 25.00 28.00 40.00 3.00 50.00 77.00 36.00 45.00
|
|
(**) S3: clocks: 0.00 0.00 79.00 31.00 94.00 65.00 75.00 71.00
|
|
------------------------------------------------------
|
|
Possible driving frequencies in MHz
|
|
|
|
(--) S3: Maximum allowed dot-clock: 110MHz
|
|
------
|
|
Bandwidth
|
|
(**) S3: Mode "1024x768": mode clock = 79.000, clock used = 79.000
|
|
(--) S3: Virtual resolution set to 1024x768
|
|
(--) S3: Using a banksize of 64k, line width of 1024
|
|
(--) S3: Pixmap cache:
|
|
(--) S3: Using 2 128-pixel 4 64-pixel and 8 32-pixel slots
|
|
(--) S3: Using 8 pages of 768x255 for font caching
|
|
</verb>
|
|
|
|
If you're using SGCS or X/Inside X:
|
|
|
|
<verb>
|
|
WGA: 86C911 (mem: 1024k clocks: 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71)
|
|
--- ------ ----- --------------------------------------------
|
|
| | | Possible driving frequencies in MHz
|
|
| | +-- Size of on-board frame-buffer RAM
|
|
| +-- Chip type
|
|
+-- Server type
|
|
</verb>
|
|
|
|
Note: do this with your machine unloaded (if at all possible). Because X is
|
|
an application, its timing loops can collide with disk activity, rendering the
|
|
numbers above inaccurate. Do it several times and watch for the numbers to
|
|
stabilize; if they don't, start killing processes until they do. Your
|
|
mouse daemon process, if you have one, is particularly likely to trip
|
|
you up (that's gpm for Linux users, mousemgr for SVr4 users).
|
|
|
|
In order to avoid the clock-probe inaccuracy, you should clip out the clock
|
|
timings and put them in your Xconfig as the value of the Clocks property ---
|
|
this suppresses the timing loop and gives X an exact list of the clock values
|
|
it can try. Using the data from the example above:
|
|
|
|
<verb>
|
|
wga
|
|
Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71
|
|
</verb>
|
|
|
|
On systems with a highly variable load, this may help you avoid mysterious X
|
|
startup failures. It's possible for X to come up, get its timings wrong due
|
|
to system load, and then not be able to find a matching dot clock in its
|
|
config database --- or find the wrong one!
|
|
|
|
<sect1>What these basic statistics control
|
|
<p>
|
|
The sync frequency ranges of your monitor, together with your video adapter's
|
|
dot clock, determine the ultimate resolution that you can use. But it's up to
|
|
the driver to tap the potential of your hardware. A superior hardware
|
|
combination without an equally competent device driver is a waste of money.
|
|
On the other hand, with a versatile device driver but less capable hardware,
|
|
you can push the hardware's envelope a little. This is the design philosophy
|
|
of XFree86.
|
|
|
|
You should match the dot clock you use to the monitor's video
|
|
bandwidth. There's a lot of give here, though --- some monitors can
|
|
run as much as 30% over their nominal bandwidth. The risks here have
|
|
to do with exceeding the monitor's rated vertical-sync frequency;
|
|
we'll discuss them in detail below.
|
|
|
|
Knowing the bandwidth will enable you to make more intelligent choices
|
|
between possible configurations. It may affect your display's visual
|
|
quality (especially sharpness for fine details).
|
|
|
|
<sect>Interpreting the Basic Specifications<label id="specs">
|
|
<p>
|
|
|
|
This section explains what the specifications above mean, and some other
|
|
things you'll need to know. First, some definitions. Next to each in parens
|
|
is the variable name we'll use for it when doing calculations
|
|
|
|
<descrip>
|
|
<tag/horizontal sync frequency (HSF)/
|
|
Horizontal scans per second (see above).
|
|
|
|
<tag/vertical sync frequency (VSF) /
|
|
Vertical scans per second (see above). Mainly important as the upper
|
|
limit on your refresh rate.
|
|
|
|
<tag/dot clock (DCF)/
|
|
More formally, `driving clock frequency'; The frequency of the
|
|
crystal or VCO on your adaptor --- the maximum dots-per-second it can
|
|
emit.
|
|
|
|
<tag/video bandwidth (VB)/
|
|
The highest frequency you can feed into your monitor's video
|
|
input and still expect to see anything discernible. If your adaptor
|
|
produces an alternating on/off pattern, its lowest frequency is half
|
|
the DCF, so in theory bandwidth starts making sense at DCF/2. For
|
|
tolerately crisp display of fine details in the video image, however,
|
|
you don't want it much below your highest DCF, and preferably higher.
|
|
|
|
<tag/frame length (HFL, VFL)/
|
|
Horizontal frame length (HFL) is the number of dot-clock ticks
|
|
needed for your monitor's electron gun to scan one horizontal line,
|
|
<em>including the inactive left and right borders</em>. Vertical
|
|
frame length (VFL) is the number of scan lines in the
|
|
<em>entire</em> image, including the inactive top and bottom
|
|
borders.
|
|
|
|
<tag/screen refresh rate (RR)/
|
|
The number of times per second your screen is repainted (this is
|
|
also called "frame rate"). Higher frequencies are better, as they
|
|
reduce flicker. 60Hz is good, VESA-standard 72Hz is better.
|
|
Compute it as
|
|
<tscreen><verb>
|
|
RR = DCF / (HFL * VFL)
|
|
</verb></tscreen>
|
|
|
|
Note that the product in the denominator is <em>not</em> the same
|
|
as the monitor's visible resolution, but typically somewhat larger.
|
|
We'll get to the details of this below.
|
|
|
|
The rates for which interlaced modes are usually specified (like 87Hz
|
|
interlaced) are actually the half-frame rates: an entire screen seems
|
|
to have about that flicker frequency for typical displays, but every
|
|
single line is refreshed only half as often.
|
|
|
|
For calculation purposes we reckon an interlaced display at its
|
|
full-frame (refresh) rate, i.e. 43.5Hz. The quality of an interlaced
|
|
mode is better than that of a non-interlaced mode with the same
|
|
full-frame rate, but definitely worse then the non-interlaced one
|
|
corresponding to the half-frame rate.
|
|
</descrip>
|
|
|
|
<sect1>About Bandwidth
|
|
<p>
|
|
|
|
Monitor makers like to advertise high bandwidth because it constrains the
|
|
sharpness of intensity and color changes on the screen. A high bandwidth
|
|
means smaller visible details.
|
|
|
|
Your monitor uses electronic signals to present an image to
|
|
your eyes. Such signals always come in in wave form once they are converted
|
|
into analog form from digitized form. They can be considered as combinations
|
|
of many simpler wave forms each one of which has a fixed frequency, many of
|
|
them are in the Mhz range, eg, 20Mhz, 40Mhz, or even 70Mhz. Your monitor
|
|
video bandwidth is, effectively, the highest-frequency analog signal it can
|
|
handle without distortion.
|
|
|
|
For our purposes, <idx>video bandwidth</idx> is mainly important as an
|
|
approximate cutoff point for the highest dot clock you can use.
|
|
|
|
<sect1>Sync Frequencies and the Refresh Rate:
|
|
<p>
|
|
|
|
Each horizontal scan line on the display is just the visible portion of a
|
|
frame-length scan. At any instant there is actually only one dot active on
|
|
the screen, but with a fast enough refresh rate your eye's persistence of
|
|
vision enables you to "see" the whole image.
|
|
|
|
Here are some pictures to help:
|
|
|
|
<verb>
|
|
_______________________
|
|
| | The horizontal sync frequency
|
|
|->->->->->->->->->->-> | is the number of times per
|
|
| )| second that the monitor's
|
|
|<-----<-----<-----<--- | electron beam can trace
|
|
| | a pattern like this
|
|
| |
|
|
| |
|
|
| |
|
|
|_______________________|
|
|
_______________________
|
|
| ^ | The vertical sync frequency
|
|
| ^ | | is the number of times per
|
|
| | v | second that the monitor's
|
|
| ^ | | electron beam can trace
|
|
| | | | a pattern like this
|
|
| ^ | |
|
|
| | v |
|
|
| ^ | |
|
|
|_______|_v_____________|
|
|
</verb>
|
|
|
|
Remember that the actual raster scan is a very tight zigzag pattern; that is,
|
|
the beam moves left-right and at the same time up-down.
|
|
|
|
Now we can see how the dot clock and frame size relates to refresh rate. By
|
|
definition, one hertz (hz) is one cycle per second. So, if your horizontal
|
|
frame length is HFL and your vertical frame length is VFL, then to cover the
|
|
entire screen takes (HFL * VFL) ticks. Since your card emits DCF ticks per
|
|
second by definition, then obviously your monitor's electron gun(s) can sweep
|
|
the screen from left to right and back and from bottom to top and back DCF /
|
|
(HFL * VFL) times/sec. This is your screen's refresh rate, because it's how
|
|
many times your screen can be updated (thus <em>refreshed</em>) per second!
|
|
|
|
You need to understand this concept to design a configuration which trades off
|
|
resolution against flicker in whatever way suits your needs.
|
|
|
|
For those of you who handle visuals better than text, here is one:
|
|
|
|
<verb>
|
|
RR VB
|
|
| min HSF max HSF |
|
|
| | R1 R2 | |
|
|
max VSF -+----|------------/----------/---|------+----- max VSF
|
|
| |:::::::::::/::::::::::/:::::\ |
|
|
| \::::::::::/::::::::::/:::::::\ |
|
|
| |::::::::/::::::::::/:::::::::| |
|
|
| |:::::::/::::::::::/::::::::::\ |
|
|
| \::::::/::::::::::/::::::::::::\ |
|
|
| \::::/::::::::::/::::::::::::::| |
|
|
| |::/::::::::::/:::::::::::::::| |
|
|
| \/::::::::::/:::::::::::::::::\|
|
|
| /\:::::::::/:::::::::::::::::::|
|
|
| / \:::::::/::::::::::::::::::::|\
|
|
| / |:::::/:::::::::::::::::::::| |
|
|
| / \::::/::::::::::::::::::::::| \
|
|
min VSF -+----/-------\--/-----------------------|--\--- min VSF
|
|
| / \/ | \
|
|
+--/----------/\------------------------+----\- DCF
|
|
R1 R2 \ | \
|
|
min HSF | max HSF
|
|
VB
|
|
</verb>
|
|
|
|
This is a generic monitor mode diagram. The x axis of the diagram
|
|
shows the clock rate (DCF), the y axis represents the refresh rate
|
|
(RR). The filled region of the diagram describes the monitor's
|
|
capabilities: every point within this region is a possible video
|
|
mode.
|
|
|
|
The lines labeled `R1' and `R2' represent a fixed resolutions (such as
|
|
640x480); they are meant to illustrate how one resolution can be realized
|
|
by many different combinations of dot clock and refresh rate. The R2
|
|
line would represent a higher resolution than R1.
|
|
|
|
The top and bottom boundaries of the permitted region are simply
|
|
horizontal lines representing the limiting values for the vertical sync
|
|
frequency. The video bandwidth is an upper limit to the clock rate and
|
|
hence is represented by a vertical line bounding the capability region on
|
|
the right.
|
|
|
|
Under <ref id="cplot" name="Plotting Monitor Capabilities">) you'll
|
|
find a program that will help you plot a diagram like
|
|
this (but much nicer, with X graphics) for your individual monitor.
|
|
That section also discusses the interesting part; the derivation of
|
|
the boundaries resulting from the limits on the horizontal sync
|
|
frequency.
|
|
|
|
<sect>Tradeoffs in Configuring your System<label id="trade">
|
|
<p>
|
|
|
|
Another way to look at the formula we derived above is
|
|
|
|
<tscreen><verb>
|
|
DCF = RR * HFL * VFL
|
|
</verb></tscreen>
|
|
That is, your dot clock is fixed. You can use those dots per second to buy
|
|
either refresh rate, horizontal resolution, or vertical resolution. If one
|
|
of those increases, one or both of the others must decrease.
|
|
|
|
Note, though, that your refresh rate cannot be greater than the maximum
|
|
vertical sync frequency of your monitor. Thus, for any given monitor at a
|
|
given dot clock, there is a minimum product of frame lengths below which you
|
|
can't force it.
|
|
|
|
In choosing your settings, remember: if you set RR too low, you will
|
|
get mugged by screen flicker. Keep it above 60Hz. 72Hz is the VESA
|
|
ergonomic standard. 120Hz is the flicker rate of fluorescent lights;
|
|
if you're sensitive to those, you need to keep it above that.
|
|
|
|
Flicker is very eye-fatiguing, though human eyes are adaptable and peoples'
|
|
tolerance for it varies widely. If you face your monitor at a 90% viewing
|
|
angle, are using a dark background and a good contrasting color for
|
|
foreground, and stick with low to medium intensity, you *may* be comfortable
|
|
at as little as 45Hz.
|
|
|
|
The acid test is this: open a xterm with pure white back-ground and black
|
|
foreground using <tt>xterm -bg white -fg black</tt> and make it so large as
|
|
to cover the entire viewable area. Now turn your monitor's intensity to 3/4 of
|
|
its maximum setting, and turn your face away from the monitor. Try peeking at
|
|
your monitor sideways (bringing the more sensitive peripheral-vision cells into
|
|
play). If you don't sense any flicker or if you feel the flickering is
|
|
tolerable, then that refresh rate is fine with you. Otherwise you better
|
|
configure a higher refresh rate, because that semi-invisible flicker is going
|
|
to fatigue your eyes like crazy and give you headaches, even if the screen
|
|
looks OK to normal vision.
|
|
|
|
For interlaced modes, the amount of flicker depends on more factors
|
|
such as the current vertical resolution and the actual screen
|
|
contents. So just experiment. You won't want to go much below about
|
|
85Hz half frame rate, though.
|
|
|
|
So let's say you've picked a minimum acceptable refresh rate. In choosing
|
|
your HFL and VFL, you'll have some room for maneuver.
|
|
|
|
<sect>Memory Requirements<label id="sizes">
|
|
<p>
|
|
Available frame-buffer RAM may limit the resolution you can achieve on color or
|
|
gray-scale displays. It probably isn't a factor on displays that have only two
|
|
colors, white and black with no shades of gray in between.
|
|
|
|
For 256-color displays, a byte of video memory is required for each
|
|
visible dot to be shown. This byte contains the information that
|
|
determines what mix of red, green, and blue is generated for its dot.
|
|
To get the amount of memory required, multiply the number of visible
|
|
dots per line by the number of visible lines. For a display with a
|
|
resolution of 1024x768, this would be 1024 x 768 = 786432, which is
|
|
the number of visible dots on the display. This is also, at one byte
|
|
per dot, the number of bytes of video memory that will be necessary on
|
|
your adapter card.
|
|
|
|
Thus, your memory requirement will typically be (HR * VR)/1024 Kbytes of VRAM,
|
|
rounded up (it would come to 768K exactly in this example). If you have more
|
|
memory than strictly required, you'll have extra for virtual-screen panning.
|
|
|
|
However, if you only have 512K on board yor video card, then you won't
|
|
be able to use this resolution. Even if you have a good monitor,
|
|
without enough video RAM, you can't take advantage of your monitor's
|
|
potential. On the other hand, if your SVGA has one meg, but your
|
|
monitor can display at most 800x600, then high resolution is beyond
|
|
your reach anyway (see <ref id="inter" name="Using Interlaced Modes">
|
|
for a possible remedy).
|
|
|
|
Don't worry if you have more memory than required; XFree86 will make
|
|
use of it by allowing you to scroll your viewable area (see the
|
|
Xconfig file documentation on the virtual screen size parameter).
|
|
Remember also that a card with 512K bytes of memory really doesn't
|
|
have 512,000 bytes installed, it has 512 x 1024 = 524,288 bytes.
|
|
|
|
If you're running X/Inside using an S3 card, and are willing to live
|
|
with 16 colors (4 bits per pixel), you can set depth 4 in Xconfig and
|
|
effectively double the resolution your card can handle. S3 cards, for
|
|
example, normally do 1024x768x256. You can make them do 1280x1024x16
|
|
with depth 4.
|
|
|
|
<sect>Computing Frame Sizes<label id="frame">
|
|
<p>
|
|
|
|
Warning: this method was developed for multisync monitors. It will probably
|
|
work with fixed-frequency monitors as well, but no guarantees!
|
|
|
|
Start by dividing DCF by your highest available HSF to get a horizontal
|
|
frame length.
|
|
|
|
For example; suppose you have a Sigma Legend SVGA with a 65MHz dot clock, and
|
|
your monitor has a 55KHz horizontal scan frequency. The quantity (DCF / HSF)
|
|
is then 1181 (65MHz = 65000KHz; 65000/55 = 1181).
|
|
|
|
Now for our first bit of black magic. You need to round this figure to the
|
|
nearest multiple of 8. This has to do with the VGA hardware controller used by
|
|
SVGA and S3 cards; it uses an 8-bit register, left-shifted 3 bits, for what's
|
|
really an 11-bit quantity. Other card types such as ATI 8514/A may not have
|
|
this requirement, but we don't know and the correction can't hurt. So round
|
|
the usable horizontal frame length figure down to 1176.
|
|
|
|
This figure (DCF / HSF rounded to a multiple of 8) is the minimum HFL you can
|
|
use. You can get longer HFLs (and thus, possibly, more horizontal dots on the
|
|
screen) by setting the sync pulse to produce a lower HSF. But you'll pay with
|
|
a slower and more visible flicker rate.
|
|
|
|
As a rule of thumb, 80% of the horizontal frame length is available for
|
|
horizontal resolution, the visible part of the horizontal scan line (this
|
|
allows, roughly, for borders and sweepback time -- that is, the time required
|
|
for the beam to move from the right screen edge to the left edge of the next
|
|
raster line). In this example, that's 944 ticks.
|
|
|
|
Now, to get the normal 4:3 screen aspect ratio, set your vertical resolution
|
|
to 3/4ths of the horizontal resolution you just calculated. For this
|
|
example, that's 708 ticks. To get your actual VFL, multiply that by 1.05
|
|
to get 743 ticks.
|
|
|
|
The 4:3 is not technically magic; nothing prevents you from using a
|
|
different ratio if that will get the best use out of your screen real
|
|
estate. It does make figuring frame height and frame width from the
|
|
diagonal size convenient, you just multiply the diagonal by by 0.8 to
|
|
get width and 0.6 to get height.
|
|
|
|
So, HFL=1176 and VFL=743. Dividing 65MHz by the product of the two gives
|
|
us a nice, healthy 74.4Hz refresh rate. Excellent! Better than VESA standard!
|
|
And you got 944x708 to boot, more than the 800 by 600 you were probably
|
|
expecting. Not bad at all!
|
|
|
|
You can even improve the refresh rate further, to almost 76 Hz, by using the
|
|
fact that monitors can often sync horizontally at 2khz or so higher than rated,
|
|
and by lowering VFL somewhat (that is, taking less than 75% of 944 in the
|
|
example above). But before you try this "overdriving" maneuver, if you do,
|
|
make <em>sure</em> that your monitor electron guns can sync up to 76 Hz
|
|
vertical. (the popular NEC 4D, for instance, cannot. It goes only up to 75 Hz
|
|
VSF). (See <ref id="overd" name="Overdriving Your Monitor"> for more general
|
|
discussion of this issue. )
|
|
|
|
So far, most of this is simple arithmetic and basic facts about raster
|
|
displays. Hardly any black magic at all!
|
|
|
|
<sect>Black Magic and Sync Pulses<label id="magic">
|
|
<p>
|
|
|
|
OK, now you've computed HFL/VFL numbers for your chosen dot clock, found the
|
|
refresh rate acceptable, and checked that you have enough VRAM. Now for the
|
|
real black magic -- you need to know when and where to place synchronization
|
|
pulses.
|
|
|
|
The sync pulses actually control the horizontal and vertical scan frequencies
|
|
of the monitor. The HSF and VSF you've pulled off the spec sheet are nominal,
|
|
approximate maximum sync frequencies. The sync pulse in the signal from the
|
|
adapter card tells the monitor how fast to actually run.
|
|
|
|
Recall the two pictures above? Only part of the time required for
|
|
raster-scanning a frame is used for displaying viewable image (ie. your
|
|
resolution).
|
|
|
|
<sect1>Horizontal Sync:
|
|
<p>
|
|
|
|
By previous definition, it takes HFL ticks to trace the a horizontal scan line.
|
|
Let's call the visible tick count (your horizontal screen resolution) HR. Then
|
|
Obviously, HR < HFL by definition. For concreteness, let's assume both start
|
|
at the same instant as shown below:
|
|
|
|
<verb>
|
|
|___ __ __ __ __ __ __ __ __ __ __ __ __
|
|
|_ _ _ _ _ _ _ _ _ _ _ _ |
|
|
|_______________________|_______________|_____
|
|
0 ^ ^ unit: ticks
|
|
| ^ ^ |
|
|
HR | | HFL
|
|
| |<----->| |
|
|
|<->| HSP |<->|
|
|
HGT1 HGT2
|
|
</verb>
|
|
|
|
Now, we would like to place a sync pulse of length HSP as shown above, ie,
|
|
between the end of clock ticks for display data and the end of clock ticks for
|
|
the entire frame. Why so? because if we can achieve this, then your screen
|
|
image won't shift to the right or to the left. It will be where it supposed to
|
|
be on the screen, covering squarely the monitor's viewable area.
|
|
|
|
Furthermore, we want about 30 ticks of "guard time" on either side of the sync
|
|
pulse. This is represented by HGT1 and HGT2. In a typical configuration HGT1
|
|
!= HGT2, but if you're building a configuration from scratch, you want to start
|
|
your experimentation with them equal (that is, with the sync pulse centered).
|
|
|
|
The symptom of a misplaced sync pulse is that the image is displaced on the
|
|
screen, with one border excessively wide and the other side of the image
|
|
wrapped around the screen edge, producing a white edge line and a band of
|
|
"ghost image" on that side. A way-out-of-place vertical sync pulse can
|
|
actually cause the image to roll like a TV with a mis-adjusted vertical hold
|
|
(in fact, it's the same phenomenon at work).
|
|
|
|
If you're lucky, your monitor's sync pulse widths will be documented on its
|
|
specification page. If not, here's where the real black magic starts...
|
|
|
|
You'll have to do a little trial and error for this part. But most of the
|
|
time, we can safely assume that a sync pulse is about 3.5 to 4.0 microsecond
|
|
in length.
|
|
|
|
For concretness again, let's take HSP to be 3.8 microseconds (which btw, is not
|
|
a bad value to start with when experimenting).
|
|
|
|
Now, using the 65Mhz clock timing above, we know HSP is equivalent to 247 clock
|
|
ticks (= 65 * 10**6 * 3.8 * 10^-6) [recall M=10^6, micro=10^-6]
|
|
|
|
Some makers like to quote their horizontal framing parameters as timings rather
|
|
than dot widths. You may see the following terms:
|
|
<descrip>
|
|
<tag/active time (HAT)/
|
|
Corresponds to HR, but in time units (usually microseconds).
|
|
HAT * DCF = HR.<p>
|
|
<tag/blanking time (HBT)/
|
|
Corresponds to (HFL - HR), but in time units (usually
|
|
microseconds). HBT * DCF = (HFL - HR).<p>
|
|
<tag/front porch (HFP)/
|
|
This is just HGT1.<p>
|
|
<tag/sync time/
|
|
This is just HSP.<p>
|
|
<tag/back porch (HBP)/
|
|
This is just HGT2.<p>
|
|
</descrip>
|
|
|
|
<sect1>Vertical Sync:
|
|
<p>
|
|
|
|
Going back to the picture above, how do we place the 247 clock ticks as shown
|
|
in the picture?
|
|
|
|
Using our example, HR is 944 and HFL is 1176. The difference between the two
|
|
is 1176 - 944=232 < 247! Obviously we have to do some adjustment here. What
|
|
can we do?
|
|
|
|
The first thing is to raise 1176 to 1184, and lower 944 to 936. Now the
|
|
difference = 1184-936= 248. Hmm, closer.
|
|
|
|
Next, instead using 3.8, we use 3.5 for calculating HSP; then, we have
|
|
65*3.5=227. Looks better. But 248 is not much higher than 227. It's normally
|
|
necessary to have 30 or so clock ticks between HR and the start of SP, and the
|
|
same for the end of SP and HFL. AND they have to be multiple of eight! Are we
|
|
stuck?
|
|
|
|
No. Let's do this, 936 % 8 = 0, (936 + 32) % 8 = 0 too. But 936 + 32 = 968,
|
|
968 + 227 = 1195, 1195 + 32 = 1227. Hmm.. this looks not too bad. But it's
|
|
not a multiple of 8, so let's round it up to 1232.
|
|
|
|
But now we have potential trouble, the sync pulse is no longer placed right in
|
|
the middle between h and H any more. Happily, using our calculator we find
|
|
1232 - 32 = 1200 is also a multiple of 8 and (1232 - 32) - 968 = 232
|
|
corresponding using a sync pulse of 3.57 microseconds long, still
|
|
reasonable.
|
|
|
|
In addition, 936/1232 ~ 0.76 or 76%, still not far from 80%, so it should be
|
|
all right.
|
|
|
|
Furthermore, using the current horizontal frame length, we basically ask our
|
|
monitor to sync at 52.7khz (= 65Mhz/1232) which is within its capability. No
|
|
problems.
|
|
|
|
Using rules of thumb we mentioned before, 936*75%=702, This is our new vertical
|
|
resolution. 702 * 1.05 = 737, our new vertical frame length.
|
|
|
|
Screen refresh rate = 65Mhz/(737*1232)=71.6 Hz. This is still excellent.
|
|
|
|
Figuring the vertical sync pulse layout is similar:
|
|
|
|
<verb>
|
|
|___ __ __ __ __ __ __ __ __ __ __ __ __
|
|
|_ _ _ _ _ _ _ _ _ _ _ _ |
|
|
|_______________________|_______________|_____
|
|
0 VR VFL unit: ticks
|
|
^ ^ ^
|
|
| | |
|
|
|<->|<----->|
|
|
VGT VSP
|
|
</verb>
|
|
|
|
We start the sync pulse just past the end of the vertical display data ticks.
|
|
VGT is the vertical guard time required for the sync pulse. Most monitors are
|
|
comfortable with a VGT of 0 (no guard time) and we'll use that in this
|
|
example. A few need two or three ticks of guard time, and it usually doesn't
|
|
hurt to add that.
|
|
|
|
Returning to the example: since by the defintion of frame length, a vertical
|
|
tick is the time for tracing a complete HORIZONTAL frame, therefore in our
|
|
example, it is 1232/65Mhz=18.95us.
|
|
|
|
Experience shows that a vertical sync pulse should be in the range of 50us and
|
|
300us. As an example let's use 150us, which translates into 8 vertical clock
|
|
ticks (150us/18.95us~8).
|
|
|
|
Some makers like to quote their vertical framing parameters as timings rather
|
|
than dot widths. You may see the following terms:
|
|
|
|
<descrip>
|
|
<tag/active time (VAT)/
|
|
Corresponds to VR, but in milliseconds. VAT * VSF = VR.
|
|
<tag/blanking time (VBT)/
|
|
Corresponds to (VFL - VR), but in milliseconds. VBT * VSF = (VFL - VR).
|
|
<tag/front porch (VFP)/
|
|
This is just VGT.
|
|
<tag/sync time/
|
|
This is just VSP.
|
|
<tag/back porch (VBP)/
|
|
This is like a second guard time after the vertical sync pulse. It
|
|
is often zero.
|
|
</descrip>
|
|
|
|
<sect>Putting it All Together<label id="synth">
|
|
<p>
|
|
|
|
The Xconfig file Table of Video Modes contains lines of numbers, with each line
|
|
being a complete specification for one mode of X-server operation. The fields
|
|
are grouped into four sections, the name section, the clock frequency section,
|
|
the horizontal section, and the vertical section.
|
|
|
|
The name section contains one field, the name of the video mode specified by
|
|
the rest of the line. This name is referred to on the "Modes" line of the
|
|
Graphics Driver Setup section of the Xconfig file. The name field may be
|
|
omitted if the name of a previous line is the same as the current line.
|
|
|
|
The dot clock section contains only the dot clock (what we've called DCF) field
|
|
of the video mode line. The number in this field specifies what dot clock was
|
|
used to generate the numbers in the following sections.
|
|
|
|
The horizontal section consists of four fields which specify how each
|
|
horizontal line on the display is to be generated. The first field of
|
|
the section contains the number of dots per line which will be
|
|
illuminated to form the picture (what we've called HR). The second
|
|
field of the section (SH1) indicates at which dot the horizontal sync
|
|
pulse will begin. The third field (SH2) indicates at which dot the
|
|
horizontal sync pulse will end. The fourth field specifies the toal
|
|
horzontal frame length (HFL).
|
|
|
|
The vertical section also contains four fields. The first field
|
|
contains the number of visible lines which will appear on the display
|
|
(VR). The second field (SV1) indicates the line number at which the
|
|
vertical sync pulse will begin. The third field (SV2) specifies the
|
|
line number at which the vertical sync pulse will end. The fourth
|
|
field contains the total vertical frame length (VFL).
|
|
|
|
Example:
|
|
<tscreen><verb>
|
|
#Modename clock horizontal timing vertical timing
|
|
|
|
"752x564" 40 752 784 944 1088 564 567 569 611
|
|
44.5 752 792 976 1240 564 567 570 600
|
|
</verb></tscreen>
|
|
(Note: stock X11R5 doesn't support fractional dot clocks.)
|
|
|
|
For Xconfig, all of the numbers just mentioned - the number of illuminated dots
|
|
on the line, the number of dots separating the illuminated dots from the
|
|
beginning of the sync pulse, the number of dots representing the duration of
|
|
the pulse, and the number of dots after the end of the sync pulse - are added
|
|
to produce the number of dots per line. The number of horizontal dots must be
|
|
evenly divisible by eight.
|
|
|
|
Example horizontal numbers: 800 864 1024 1088
|
|
|
|
This sample line has the number of illuminated dots (800) followed by the
|
|
number of the dot when the sync pulse starts (864), followed by the number of
|
|
the dot when the sync pulse ends (1024), followed by the number of the last dot
|
|
on the horizontal line (1088).
|
|
|
|
Note again that all of the horizontal numbers (800, 864, 1024, and 1088) are
|
|
divisible by eight! This is not required of the vertical numbers.
|
|
|
|
The number of lines from the top of the display to the bottom form the frame.
|
|
The basic timing signal for a frame is the line. A number of lines will
|
|
contain the picture. After the last illuminated line has been displayed, a
|
|
delay of a number of lines will occur before the vertical sync pulse is
|
|
generated. Then the sync pulse will last for a few lines, and finally the last
|
|
lines in the frame, the delay required after the pulse, will be generated. The
|
|
numbers that specify this mode of operation are entered in a manner similar to
|
|
the following example.
|
|
|
|
Example vertical numbers: 600 603 609 630
|
|
|
|
This example indicates that there are 600 visible lines on the display, that
|
|
the vertical sync pulse starts with the 603rd line and ends with the 609th, and
|
|
that there are 630 total lines being used.
|
|
|
|
Note that the vertical numbers don't have to be divisible by eight!
|
|
|
|
Let's return to the example we've been working. According to the above, all
|
|
we need to do from now on is to write our result into Xconfig as follows:
|
|
<tscreen><verb>
|
|
<name> DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
|
|
</verb></tscreen>
|
|
where SH1 is the start tick of the horizontal sync pulse and SH2 is its end
|
|
tick; similarly, SV1 is the start tick of the vertical sync pulse and SV2 is
|
|
its end tick.
|
|
|
|
To place these, recall the discussion of black magic and sync pulses
|
|
given above. SH1 is the dot that begins the leading edge of the horiziontal
|
|
sync pulse; thus, SH1 = HR + HGT1. SH2 is the trailing edge; thus,
|
|
SH2 = SH1 + HSP. Similarly, SV1 = VR + VGT (but VGT is usually zero)
|
|
and SV2 = SV1 + VSP.
|
|
|
|
<tscreen><verb>
|
|
#name clock horizontal timing vertical timing flag
|
|
936x702 65 936 968 1200 1232 702 702 710 737
|
|
</verb></tscreen>
|
|
No special flag necessary; this is a non-interlaced mode. Now we are really
|
|
done.
|
|
|
|
<sect>Overdriving Your Monitor<label id="overd">
|
|
<p>
|
|
|
|
You should absolutely <EM>not</EM> try exceeding your monitor's scan
|
|
rates if it's a fixed-frequency type. You can smoke your hardware
|
|
doing this! There are potentially subtler problems with overdriving a
|
|
multisync monitor which you should be aware of.
|
|
|
|
Having a pixel clock higher than the monitor's maximum bandwidth is
|
|
rather harmless, in contrast. It's exceeding the rated maximum sync
|
|
frequencies that's problematic. Some modern monitors might have
|
|
protection circuitry that shuts the monitor down at dangerous scan
|
|
rates, but don't rely on it. In particular there are older multisync
|
|
monitors (like the Multisync II) which use just one horizontal
|
|
transformer. These monitors will not have much protection against
|
|
overdriving them. While you necessarily have high voltage regulation
|
|
circuitry (which can be absent in fixed frequency monitors), it will
|
|
not necessarily cover every conceivable frequency range, especially in
|
|
cheaper models. This not only implies more wear on the circuitry, it
|
|
can also cause the screen phosphors to age faster, and cause more than
|
|
the specified radiation (including X-rays) to be emitted from the
|
|
monitor.
|
|
|
|
<!--
|
|
(Note: the theoretical limit of discernable features is reached when
|
|
the pixel clock reaches double the monitor's bandwidth. This is a
|
|
straightforward application of Nyquist's Theorem: consider the pixels
|
|
as a spatially distributed series of samples of the drive signals and
|
|
you'll see why.)
|
|
|
|
Payne Freret wrote:
|
|
Only if the monitor's video passband has the characteristic of a
|
|
brick-wall filter with a cutoff frequency of one half the pixel
|
|
rate would alternating black-and-white pixels merge to grey. The
|
|
video passband of monitors is deliberately not a brick-wall filter
|
|
(such a passband would produced undesirable ringing), and so
|
|
pixels can still be discerned even when the pixel clock is twice
|
|
the monitor's "bandwidth." An alternating black-white pixel
|
|
stream would, for the most part, be filtered to a sine wave, but
|
|
the individual pixels would still be discernible.
|
|
|
|
Nyquist theory doesn't apply here, since we're talking video
|
|
bandwidth and the continuous video signal was constructed before
|
|
it got to the monitor. While one might argue that the CRT
|
|
color-triads sample the video signal, this is a different issue.
|
|
Moreover, the triad sampling rate is comparable to pixel spatial
|
|
frequency, not to one-half the pixel spatial frequency. This
|
|
empirical relationship is why, I suspect, one finds very high
|
|
resolutions only on very big monitors. The practical limit of
|
|
0.23 to 0.28 triads/mm blurs very high resolution on small CRTs.
|
|
|
|
|
|
Another importance of the bandwidth is that the monitor's input
|
|
impedance is specified only for that range, and using higher
|
|
frequencies can cause reflections probably causing minor screen
|
|
interferences, and radio disturbance.
|
|
|
|
Payne Freret wrote:
|
|
From my experience as a designer monitors usually have a pretty
|
|
constant input impedance comprising a simple resistive termination
|
|
and some small unavoidable capacitance. The reason higher pixel
|
|
rates seem to produce distortion is that higher pixel rates
|
|
usually arise from operating at high screen resolution rather than
|
|
operating at high refresh rates. When the monitor is operated at
|
|
high screen resolution, the screen details are finer and
|
|
reflections that arise from cable-monitor impedance mismatches or
|
|
from lousy cables, and which were present even at lower screen
|
|
resolutions, produce echos that constitute larger proportion of
|
|
the finest detail. Consequently they are more conspicuous.
|
|
-->
|
|
|
|
However, the basic problematic magnitude in question here is the slew
|
|
rate (the steepness of the video signals) of the video output drivers,
|
|
and that is usually independent of the actual pixel frequency, but
|
|
(if your board manufacturer cares about such problems) related
|
|
to the maximum pixel frequency of the board.
|
|
|
|
So be careful out there...
|
|
|
|
<sect>Using Interlaced Modes<label id="inter">
|
|
<p>
|
|
|
|
(This section is largely due to David Kastrup
|
|
<dak@pool.informatik.rwth-aachen.de>)
|
|
|
|
At a fixed dot clock, an interlaced display is going to have
|
|
considerably less noticable flicker than a non-interlaced display, if
|
|
the vertical circuitry of your monitor is able to support it stably.
|
|
It is because of this that interlaced modes were invented in the first
|
|
place.
|
|
|
|
Interlaced modes got their bad repute because they are inferior to
|
|
their non-interlaced companions at the same vertical scan frequency,
|
|
VSF (which is what is usually given in advertisements). But they are
|
|
definitely superior at the same horizontal scan rate, and that's where
|
|
the decisive limits of your monitor/graphics card usually lie.
|
|
|
|
At a fixed <EM>refresh rate</EM> (or half frame rate, or VSF) the
|
|
interlaced display will flicker more: a 90Hz interlaced display will
|
|
be inferior to a 90Hz non-interlaced display. It will, however, need
|
|
only half the video bandwidth and half the horizontal scan rate. If
|
|
you compared it to a non-interlaced mode with the same dot clock and
|
|
the same scan rates, it would be vastly superior: 45Hz non-interlaced
|
|
is intolerable. With 90Hz interlaced, I have worked for years with my
|
|
Multisync 3D (at 1024x768) and am very satisfied. I'd guess you'd need
|
|
at least a 70Hz non-interlaced display for similar comfort.
|
|
|
|
You have to watch a few points, though: use interlaced modes only at
|
|
high resolutions, so that the alternately lighted lines are close
|
|
together. You might want to play with sync pulse widths and positions
|
|
to get the most stable line positions. If alternating lines are bright
|
|
and dark, interlace will <EM>jump</EM> at you. I have one application that
|
|
chooses such a dot pattern for a menu background (XCept, no other
|
|
application I know does that, fortunately). I switch to 800x600 for
|
|
using XCept because it really hurts my eyes otherwise.
|
|
|
|
For the same reason, use at least 100dpi fonts, or other fonts where
|
|
horizontal beams are at least two lines thick (for high resolutions,
|
|
nothing else will make sense anyhow).
|
|
|
|
And of course, never use an interlaced mode when your hardware would
|
|
support a non-interlaced one with similar refresh rate.
|
|
|
|
If, however, you find that for some resolution you are pushing either
|
|
monitor or graphics card to their upper limits, and getting
|
|
dissatisfactorily flickery or outwashed (bandwidth exceeded) display,
|
|
you might want to try tackling the same resolution using an
|
|
interlaced mode. Of course this is useless if the VSF
|
|
of your monitor is already close to its limits.
|
|
|
|
Design of interlaced modes is easy: do it like a non-interlaced
|
|
mode. Just two more considerations are necessary: you need an odd
|
|
total number of vertical lines (the last number in your mode line), and
|
|
when you specify the "interlace" flag, the actual vertical frame rate
|
|
for your monitor doubles. Your monitor needs to support a 90Hz frame
|
|
rate if the mode you specified looks like a 45Hz mode apart from the
|
|
"Interlace" flag.
|
|
|
|
As an example, here is my modeline for 1024x768 interlaced: my
|
|
Multisync 3D will support up to 90Hz vertical and 38kHz horizontal.
|
|
|
|
<tscreen><verb>
|
|
ModeLine "1024x768" 45 1024 1048 1208 1248 768 768 776 807 Interlace
|
|
</verb></tscreen>
|
|
|
|
Both limits are pretty much exhausted with this mode. Specifying the
|
|
same mode, just without the "Interlace" flag, still is almost at the
|
|
limit of the monitor's horizontal capacity (and strictly speaking, a
|
|
bit under the lower limit of vertical scan rate), but produces an
|
|
intolerably flickery display.
|
|
|
|
Basic design rules: if you have designed a mode at less than half of
|
|
your monitor's vertical capacity, make the vertical total of lines odd
|
|
and add the "Interlace" flag. The display's quality should vastly
|
|
improve in most cases.
|
|
|
|
If you have a non-interlaced mode otherwise exhausting your monitor's
|
|
specs where the vertical scan rate lies about 30% or more under the
|
|
maximum of your monitor, hand-designing an interlaced mode (probably
|
|
with somewhat higher resolution) could deliver superior results, but I
|
|
won't promise it.
|
|
|
|
<sect>Questions and Answers<label id="answe">
|
|
<p>
|
|
|
|
Q. The example you gave is not a standard screen size, can I use it?
|
|
|
|
A. Why not? There is NO reason whatsover why you have to use 640x480,
|
|
800x600, or even 1024x768. The XFree86 servers let you configure your hardware
|
|
with a lot of freedom. It usually takes two to three tries to come up the
|
|
right one. The important thing to shoot for is high refresh rate with
|
|
reasonable viewing area. not high resolution at the price of eye-tearing
|
|
flicker!
|
|
|
|
Q. It this the only resolution given the 65Mhz dot clock and 55Khz HSF?
|
|
|
|
A. Absolutely not! You are encouraged to follow the general procedure and
|
|
do some trial-and-error to come up a setting that's really to your liking.
|
|
Experimenting with this can be lots of fun. Most settings may just give you
|
|
nasty video hash, but in practice a modern multi-sync monitor is usually not
|
|
damaged easily. Be sure though, that your monitor can support the frame
|
|
rates of your mode before using it for longer times.
|
|
|
|
Beware fixed-frequency monitors! This kind of hacking around can damage
|
|
them rather quickly. Be sure you use valid refresh rates for <EM>every</EM>
|
|
experiment on them.
|
|
|
|
Q. You just mentioned two standard resolutions. In Xconfig, there are many
|
|
standard resolutions available, can you tell me whether there's any point in
|
|
tinkering with timings?
|
|
|
|
A. Absolutely! Take, for example, the "standard" 640x480 listed in
|
|
the current Xconfig. It employes 25Mhz driving frequency, frame
|
|
lengths are 800 and 525 => refresh rate ~ 59.5Hz. Not too bad. But
|
|
28Mhz is a commonly available driving frequency from many SVGA boards.
|
|
If we use it to drive 640x480, following the procedure we discussed
|
|
above, you would get frame lengths like 812 (round down to 808) and
|
|
505. Now the refresh rate is raised to 68Hz, a quite significant
|
|
improvement over the standard one.
|
|
|
|
Q. Can you summarize what we have discussed so far?
|
|
|
|
A. In a nutshell:
|
|
|
|
<enum>
|
|
<item>
|
|
for any fixed driving frequency, raising max resolution incurs the penalty
|
|
of lowering refresh rate and thus introducing more flicker.
|
|
<item>
|
|
if high resolution is desirable and your monitor supports it, try to
|
|
get a SVGA card that provides a matching dot clock or DCF. The higher,
|
|
the better!
|
|
</enum>
|
|
|
|
<sect>Fixing Problems with the Image.<label id="fixes">
|
|
<p>
|
|
|
|
OK, so you've got your X configuration numbers. You put them in
|
|
Xconfig with a test mode label. You fire up X, hot-key to the new
|
|
mode, ... and the image doesn't look right. What do you do? Here's a
|
|
list of common <idx>video image distortions</idx> and how to fix them.
|
|
|
|
(Fixing these minor distortions is where <bf>xvidtune</bf>(1) really shines.)
|
|
|
|
You <em>move</em> the image by changing the sync pulse timing. You
|
|
<em>scale</em> it by changing the frame length (you need to move the
|
|
sync pulse to keep it in the same relative position, otherwise scaling will
|
|
move the image as well). Here are some more specific recipes:
|
|
|
|
The horizontal and vertical positions are independent. That is, moving the
|
|
image horizontally doesn't affect placement vertically, or vice-versa.
|
|
However, the same is not quite true of scaling. While changing the horizontal
|
|
size does nothing to the vertical size or vice versa, the total change in both
|
|
may be limited. In particular, if your image is too large in both dimensions
|
|
you will probably have to go to a higher dot clock to fix it. Since this
|
|
raises the usable resolution, it is seldom a problem!
|
|
|
|
<sect1>The image is displaced to the left or right
|
|
<p>
|
|
|
|
To fix this, move the horizontal sync pulse. That is, increment or decrement
|
|
(by a multiple of 8) the middle two numbers of the horizontal timing section
|
|
that define the leading and trailing edge of the horizontal sync pulse.
|
|
|
|
If the image is shifted left (right border too large, you want to move
|
|
the image to the right) decrement the numbers. If the image is shifted right
|
|
(left border too large, you want it to move left) increment the sync pulse.
|
|
|
|
<sect1>The image is displaced up or down
|
|
<p>
|
|
|
|
To fix this, move the vertical sync pulse. That is, increment or decrement the
|
|
middle two numbers of the vertical timing section that define the leading and
|
|
trailing edge of the vertical sync pulse.
|
|
|
|
If the image is shifted up (lower border too large, you want to move the image
|
|
down) decrement the numbers. If the image is shifted down (top border too
|
|
large, you want it to move up) increment the numbers.
|
|
|
|
<sect1>The image is too large both horizontally and vertically
|
|
<p>
|
|
|
|
Switch to a higher card clock speed. If you have multiple modes in your
|
|
clock file, possibly a lower-speed one is being activated by mistake.
|
|
|
|
<sect1>The image is too wide (too narrow) horizontally
|
|
<p>
|
|
|
|
To fix this, increase (decrease) the horizontal frame length. That is, change
|
|
the fourth number in the first timing section. To avoid moving the image, also
|
|
move the sync pulse (second and third numbers) half as far, to keep it in the
|
|
same relative position.
|
|
|
|
<sect1>The image is too deep (too shallow) vertically
|
|
<p>
|
|
|
|
To fix this, increase (decrease) the vertical frame length. That is, change
|
|
the fourth number in the second timing section. To avoid moving the image,
|
|
also move the sync pulse (second and third numbers) half as far, to keep it in
|
|
the same relative position.
|
|
|
|
Any distortion that can't be handled by combining these techniques is probably
|
|
evidence of something more basically wrong, like a calculation mistake or a
|
|
faster dot clock than the monitor can handle.
|
|
|
|
Finally, remember that increasing either frame length will decrease your
|
|
refresh rate, and vice-versa.
|
|
|
|
Occasionally you can fix minor distortions by fiddling with the
|
|
picture controls on your monitor. The disadvantage is that if you
|
|
take your controls too far off the neutral (factory) setting to fix
|
|
graphics-mode problems, you may end up with a wacky image in text
|
|
mode. It's better to get your modeline right.
|
|
|
|
<sect>Plotting Monitor Capabilities<label id="cplot">
|
|
<p>
|
|
|
|
To plot a monitor mode diagram, you'll need the gnuplot package (a
|
|
freeware plotting language for UNIX-like operating systems) and the
|
|
tool <TT>modeplot</TT>, a shell/gnuplot script to plot the diagram from your
|
|
monitor characteristics, entered as command-line options.
|
|
|
|
Here is a copy of <tt>modeplot</tt>:
|
|
|
|
<verb>
|
|
#!/bin/sh
|
|
#
|
|
# modeplot -- generate X mode plot of available monitor modes
|
|
#
|
|
# Do `modeplot -?' to see the control options.
|
|
#
|
|
|
|
# Monitor description. Bandwidth in MHz, horizontal frequencies in kHz
|
|
# and vertical frequencies in Hz.
|
|
TITLE="Viewsonic 21PS"
|
|
BANDWIDTH=185
|
|
MINHSF=31
|
|
MAXHSF=85
|
|
MINVSF=50
|
|
MAXVSF=160
|
|
ASPECT="4/3"
|
|
vesa=72.5 # VESA-recommended minimum refresh rate
|
|
|
|
while [ "$1" != "" ]
|
|
do
|
|
case $1 in
|
|
-t) TITLE="$2"; shift;;
|
|
-b) BANDWIDTH="$2"; shift;;
|
|
-h) MINHSF="$2" MAXHSF="$3"; shift; shift;;
|
|
-v) MINVSF="$2" MAXVSF="$3"; shift; shift;;
|
|
-a) ASPECT="$2"; shift;;
|
|
-g) GNUOPTS="$2"; shift;;
|
|
-?) cat <<EOF
|
|
modeplot control switches:
|
|
|
|
-t "<description>" name of monitor defaults to "Viewsonic 21PS"
|
|
-b <nn> bandwidth in MHz defaults to 185
|
|
-h <min> <max> min & max HSF (kHz) defaults to 31 85
|
|
-v <min> <max> min & max VSF (Hz) defaults to 50 160
|
|
-a <aspect ratio> aspect ratio defaults to 4/3
|
|
-g "<options>" pass options to gnuplot
|
|
|
|
The -b, -h and -v options are required, -a, -t, -g optional. You can
|
|
use -g to pass a device type to gnuplot so that (for example) modeplot's
|
|
output can be redirected to a printer. See gnuplot(1) for details.
|
|
|
|
The modeplot tool was created by Eric S. Raymond <esr@thyrsus.com> based on
|
|
analysis and scratch code by Martin Lottermoser <Martin.Lottermoser@mch.sni.de>
|
|
|
|
This is modeplot $Revision$
|
|
EOF
|
|
exit;;
|
|
esac
|
|
shift
|
|
done
|
|
|
|
gnuplot $GNUOPTS <<EOF
|
|
set title "$TITLE Mode Plot"
|
|
|
|
# Magic numbers. Unfortunately, the plot is quite sensitive to changes in
|
|
# these, and they may fail to represent reality on some monitors. We need
|
|
# to fix values to get even an approximation of the mode diagram. These come
|
|
# from looking at lots of values in the ModeDB database.
|
|
F1 = 1.30 # multiplier to convert horizontal resolution to frame width
|
|
F2 = 1.05 # multiplier to convert vertical resolution to frame height
|
|
|
|
# Function definitions (multiplication by 1.0 forces real-number arithmetic)
|
|
ac = (1.0*$ASPECT)*F1/F2
|
|
refresh(hsync, dcf) = ac * (hsync**2)/(1.0*dcf)
|
|
dotclock(hsync, rr) = ac * (hsync**2)/(1.0*rr)
|
|
resolution(hv, dcf) = dcf * (10**6)/(hv * F1 * F2)
|
|
|
|
# Put labels on the axes
|
|
set xlabel 'DCF (MHz)'
|
|
set ylabel 'RR (Hz)' 6 # Put it right over the Y axis
|
|
|
|
# Generate diagram
|
|
set grid
|
|
set label "VB" at $BANDWIDTH+1, ($MAXVSF + $MINVSF) / 2 left
|
|
set arrow from $BANDWIDTH, $MINVSF to $BANDWIDTH, $MAXVSF nohead
|
|
set label "max VSF" at 1, $MAXVSF-1.5
|
|
set arrow from 0, $MAXVSF to $BANDWIDTH, $MAXVSF nohead
|
|
set label "min VSF" at 1, $MINVSF-1.5
|
|
set arrow from 0, $MINVSF to $BANDWIDTH, $MINVSF nohead
|
|
set label "min HSF" at dotclock($MINHSF, $MAXVSF+17), $MAXVSF + 17 right
|
|
set label "max HSF" at dotclock($MAXHSF, $MAXVSF+17), $MAXVSF + 17 right
|
|
set label "VESA $vesa" at 1, $vesa-1.5
|
|
set arrow from 0, $vesa to $BANDWIDTH, $vesa nohead # style -1
|
|
plot [dcf=0:1.1*$BANDWIDTH] [$MINVSF-10:$MAXVSF+20] \
|
|
refresh($MINHSF, dcf) notitle with lines 1, \
|
|
refresh($MAXHSF, dcf) notitle with lines 1, \
|
|
resolution(640*480, dcf) title "640x480 " with points 2, \
|
|
resolution(800*600, dcf) title "800x600 " with points 3, \
|
|
resolution(1024*768, dcf) title "1024x768 " with points 4, \
|
|
resolution(1280*1024, dcf) title "1280x1024" with points 5, \
|
|
resolution(1600*1280, dcf) title "1600x1200" with points 6
|
|
|
|
pause 9999
|
|
EOF
|
|
</verb>
|
|
|
|
Once you know you have <tt>modeplot</tt> and the gnuplot package in
|
|
place, you'll need the following monitor characteristics:
|
|
|
|
<itemize>
|
|
<item> video bandwidth (VB)
|
|
<item> range of horizontal sync frequency (HSF)
|
|
<item> range of vertical sync frequency (VSF)
|
|
</itemize>
|
|
|
|
The plot program needs to make some simplifying assumptions which are
|
|
not necessarily correct. This is the reason why the resulting diagram is
|
|
only a rough description. These assumptions are:
|
|
|
|
<enum>
|
|
<item> All resolutions have a single fixed aspect ratio AR = HR/VR.
|
|
Standard resolutions have AR = 4/3 or AR = 5/4. The <TT>modeplot</TT>
|
|
programs assumes 4/3 by default, but you can override this.
|
|
<item> For the modes considered, horizontal and vertical frame lengths are
|
|
fixed multiples of horizontal and vertical resolutions, respectively:
|
|
|
|
<tscreen><verb>
|
|
HFL = F1 * HR
|
|
VFL = F2 * VR
|
|
</verb></tscreen>
|
|
</enum>
|
|
|
|
As a rough guide, take F1 = 1.30 and F2 = 1.05 (see <ref id=frame>
|
|
"Computing Frame Sizes").
|
|
|
|
Now take a particular sync frequency, HSF. Given the assumptions just
|
|
presented, every value for the clock rate DCF already determines the
|
|
refresh rate RR, i.e. for every value of HSF there is a function RR(DCF).
|
|
This can be derived as follows.
|
|
|
|
The refresh rate is equal to the clock rate divided by the product of the
|
|
frame sizes:
|
|
|
|
<tscreen><verb>
|
|
RR = DCF / (HFL * VFL) (*)
|
|
</verb></tscreen>
|
|
|
|
On the other hand, the horizontal frame length is equal to the clock rate
|
|
divided by the horizontal sync frequency:
|
|
|
|
<tscreen><verb>
|
|
HFL = DCF / HSF (**)
|
|
</verb></tscreen>
|
|
|
|
VFL can be reduced to HFL be means of the two assumptions above:
|
|
|
|
<tscreen><verb>
|
|
VFL = F2 * VR
|
|
= F2 * (HR / AR)
|
|
= (F2/F1) * HFL / AR (***)
|
|
</verb></tscreen>
|
|
|
|
Inserting (**) and (***) into (*) we obtain:
|
|
|
|
<tscreen><verb>
|
|
RR = DCF / ((F2/F1) * HFL**2 / AR)
|
|
= (F1/F2) * AR * DCF * (HSF/DCF)**2
|
|
= (F1/F2) * AR * HSF**2 / DCF
|
|
</verb></tscreen>
|
|
|
|
For fixed HSF, F1, F2 and AR, this is a hyperbola in our diagram. Drawing
|
|
two such curves for minimum and maximum horizontal sync frequencies we
|
|
have obtained the two remaining boundaries of the permitted region.
|
|
|
|
The straight lines crossing the capability region represent particular
|
|
resolutions. This is based on (*) and the second assumption:
|
|
|
|
<tscreen><verb>
|
|
RR = DCF / (HFL * VFL) = DCF / (F1 * HR * F2 * VR)
|
|
</verb></tscreen>
|
|
|
|
By drawing such lines for all resolutions one is interested in, one
|
|
can immediately read off the possible relations between resolution,
|
|
clock rate and refresh rate of which the monitor is capable. Note that
|
|
these lines do not depend on monitor properties, but they do depend on
|
|
the second assumption.
|
|
|
|
The <TT>modeplot</TT> tool provides you with an easy way to do this. Do
|
|
<TT>modeplot -?</TT> to see its control options. A typical invocation
|
|
looks like this:
|
|
|
|
<tscreen><verb>
|
|
modeplot -t "Swan SW617" -b 85 -v 50 90 -h 31 58
|
|
</verb></tscreen>
|
|
|
|
The -b option specifies video bandwidth; -v and -h set horizontal and
|
|
vertical sync frequency ranges.
|
|
|
|
When reading the output of <TT>modeplot</TT>, always bear in mind that
|
|
it gives only an approximate description. For example, it disregards
|
|
limitations on HFL resulting from a minimum required sync pulse width,
|
|
and it can only be accurate as far as the assumptions are. It is
|
|
therefore no substitute for a detailed calculation (involving some
|
|
black magic) as presented in <ref id="synth" name="Putting it All
|
|
Together">. However, it should give you a better feeling for what
|
|
is possible and which tradeoffs are involved.
|
|
|
|
<sect>Credits<label id="credi">
|
|
<p>
|
|
|
|
The original ancestor of this document was by Chin Fang
|
|
<fangchin@leland.stanford.edu>.
|
|
|
|
Eric S. Raymond <esr@snark.thyrsus.com> reworked, reorganized, and
|
|
massively rewrote Chin Fang's original in an attempt to understand it. In
|
|
the process, he merged in most of a different how-to by Bob Crosson
|
|
<crosson@cam.nist.gov>.
|
|
|
|
The material on interlaced modes is largely by David Kastrup
|
|
<dak@pool.informatik.rwth-aachen.de>
|
|
|
|
Nicholas Bodley <nbodley@alumni.princeton.edu> corrected
|
|
and clarified the section on how displays work.
|
|
|
|
Payne Freret <payne@freret.org> corrected some minor technical
|
|
errors about monitor design.
|
|
|
|
Martin Lottermoser <Martin.Lottermoser@mch.sni.de> contributed
|
|
the idea of using gnuplot to make mode diagrams and did the
|
|
mathematical analysis behind <TT>modeplot</TT>. The distributed
|
|
<TT>modeplot</TT> was redesigned and generalized by ESR from
|
|
Martin's original gnuplot code for one case.
|
|
</article>
|
|
|