17. Plotting Monitor Capabilities
To plot a monitor mode diagram, you'll need the gnuplot package
(a freeware plotting language for UNIX-like operating systems) and the
tool modeplot, a shell/gnuplot script to plot the
diagram from your monitor characteristics, entered as command-line
options.
Here is a copy of modeplot:
#!/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: 1.25 $
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
|
Once you know you have modeplot and the
gnuplot package in place, you'll need the following monitor
characteristics:
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:
All resolutions have a single fixed aspect ratio AR =
HR/VR. Standard resolutions have AR = 4/3 or AR = 5/4. The
modeplot programs assumes 4/3 by default, but you
can override this.
For the modes considered, horizontal and vertical
frame lengths are fixed multiples of horizontal and vertical
resolutions, respectively:
HFL = F1 * HR
VFL = F2 * VR
|
As a rough guide, take F1 = 1.30 and F2 = 1.05 (see 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:
RR = DCF / (HFL * VFL) (*)
|
On the other hand, the horizontal frame length is equal to the clock rate
divided by the horizontal sync frequency:
VFL can be reduced to HFL be means of the two assumptions above:
VFL = F2 * VR
= F2 * (HR / AR)
= (F2/F1) * HFL / AR (***)
|
Inserting (**) and (***) into (*) we obtain:
RR = DCF / ((F2/F1) * HFL**2 / AR)
= (F1/F2) * AR * DCF * (HSF/DCF)**2
= (F1/F2) * AR * HSF**2 / DCF
|
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:
RR = DCF / (HFL * VFL) = DCF / (F1 * HR * F2 * VR)
|
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 modeplot tool provides you with an easy way to
do this. Do modeplot -? to see its control
options. A typical invocation looks like this:
modeplot -t "Swan SW617" -b 85 -v 50 90 -h 31 58
|
The -b option specifies video bandwidth; -v and -h set horizontal and
vertical sync frequency ranges.
When reading the output of modeplot, 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 Putting it All Together. However, it should give
you a better feeling for what is possible and which tradeoffs are
involved.
Fedora Core 4 Tutorial
