This commit is contained in:
gferg 2013-09-23 13:07:12 +00:00
parent 63a4597475
commit c90d1ba037
3 changed files with 71 additions and 78 deletions

View File

@ -1312,7 +1312,7 @@ How to set up a touch screen input device under XFree86. </Para>
XFree86-Video-Timings-HOWTO</ULink>,
<CiteTitle>XFree86 Video Timings HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: Jul 2003</CiteTitle>.
<CiteTitle>Updated: Sep 2013</CiteTitle>.
How to compose a mode line for your card/monitor combination under
XFree86. </Para>
</ListItem>

View File

@ -5151,7 +5151,7 @@ How to set up a touch screen input device under XFree86. </Para>
XFree86-Video-Timings-HOWTO</ULink>,
<CiteTitle>XFree86 Video Timings HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: Jul 2003</CiteTitle>.
<CiteTitle>Updated: Sep 2013</CiteTitle>.
How to compose a mode line for your card/monitor combination under
XFree86. </Para>
</ListItem>

View File

@ -1,7 +1,6 @@
<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://docbook.org/xml/4.1.2/docbookx.dtd" [
"docbook/docbookxx.dtd" [
<!ENTITY ldpsite "http://www.tldp.org/">
<!ENTITY howto "&ldpsite;HOWTO/">
<!ENTITY mini-howto "&ldpsite;HOWTO/mini/">
@ -10,7 +9,7 @@
<article>
<articleinfo>
<title>XFree86 Video Timings HOWTO</title>
<title>X.org/XFree86 Video Timings HOWTO</title>
<author>
<firstname>Eric</firstname>
@ -24,7 +23,6 @@
</address>
</affiliation>
</author>
<pubdate role="cvs">$Date$</pubdate>
<copyright>
<year>2000</year>
<holder role="mailto:esr@thyrsus.com">Eric S. Raymond</holder>
@ -32,14 +30,32 @@
<legalnotice>
<title>Copyright</title>
<para>Permission is granted to copy, distribute and/or modify
this document under the terms of the Open Publication License,
this document under the terms of the
<ulink url='http://creativecommons.org/licenses/by/2.0/'>Creative Commons Attribution License,</ulink>
version 2.0.</para>
</legalnotice>
<revhistory>
<revision>
<revnumber>6.6</revnumber>
<date>2013-09-22</date>
<authorinitials>esr</authorinitials>
<revremark>
Ten years after: minor updates for X.org. kvideogen and xf86setup are
dead, read-edid has a new home page.
</revremark>
</revision>
<revision>
<revnumber>6.5</revnumber>
<date>2003-09-28</date>
<authorinitials>esr</authorinitials>
<revremark>
License changed to Creative Commons.
</revremark>
</revision>
<revision>
<revnumber>6.4</revnumber>
<date>2003-07-14</date>
<date>2004-10-14</date>
<authorinitials>esr</authorinitials>
<revremark>
URL fixes.
@ -89,18 +105,20 @@
</revhistory>
<abstract>
<para><emphasis role="bold">This HOWTO is effectively obsolete.
Current (4.0.1 and up) versions of XFree86 compute optimal modelines
from the resolution you specify in the Modes section of your X
configuration file.</emphasis></para>
<para><emphasis role="bold">This HOWTO is effectively obsolete, and
has been so since 2003. Current versions of X compute optimal
modelines from EDID information returned by your monitor. In addition,
many of the constraints and caveats in this document applied to CRTs
but no longer apply to digital flatscreens.</emphasis></para>
<para>How to compose a mode line for your card/monitor combination
under XFree86<indexterm><primary>XFree86</primary></indexterm>. The
XFree86 distribution now includes good facilities for configuring most
under X.org<indexterm><primary>X.org</primary></indexterm> (originally
written for its ancestor
XFree86<indexterm><primary>XFree86</primary></indexterm>).
X distributions now include good facilities for configuring most
standard combinations; this document is mainly useful if you are
tuning a custom mode line for an ultra-high-performance monitor or
very unusual hardware. It may also help you in using
<application>kvideogen</application> to generate mode lines, or
<application>xvidtune</application> to tweak a standard mode that is
not quite right for your monitor.</para>
</abstract>
@ -127,12 +145,13 @@ here.</para>
</sect1>
<sect1 id="obsolete"><title>Why This HOWTO Is Obsolete</title>
<para>For 4.0.0 and later versions of XFree86, you no longer have to
generate modelines at all under most circumstances. Instead they are
computed internally by the server at startup time, based on the
resolution you specify in the Modes part of the Screen section part of
your XFree86 configuration file and the monitor capabilities your X
server gets via an EDID query to the monitor. </para>
<para>In X.org (and for 4.0.0 and later versions of the now-obsolete
XFree86) you no longer have to generate modelines at all under most
circumstances. Instead they are computed internally by the server at
startup time, based on the resolution you specify in the the monitor
capabilities your X server gets via an EDID query to the monitor (and
the Modes part of the Screen section part of your X configuration
file, if you have one). </para>
<para>To change your screen resolution and color depth, simply edit or
create a Display section describing it. Here is a sample Screen
@ -154,22 +173,21 @@ EndSection
</screen>
<para>All you will usually need to do is change the numbers in the
Mode entry. X will do the rest. If you specify an impossible
Modes entry. X will do the rest. If you specify an impossible
resolution, it will fall back to the closest approximation that the EDID
data from the monitor says it can support.</para>
<para>Therefore, the information in the remainder of this HOWTO is
useful only if (a) you have an old, pre-EDID monitor, or (b) your
graphics-card driver doesn't support querying the monitor, or (c) you
are running an old version of XFree86 (in which case, you should
are running a very old version of X (in which case, you should
fix your problem by upgrading), or (d) your monitor/card combination
can support a resolution above 1920 x 1440 or below 640 x 480, which
is the range over which XFree86 has canned modelines.</para>
operates outside the range over which X has canned modelines.</para>
</sect1>
<sect1 id="introduction"><title>Introduction</title>
<para>The XFree86 server allows users to configure their video
<para>The X 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.</para>
@ -199,52 +217,30 @@ handle.</para>
</sect1>
<sect1 id="tools"><title>Tools for Automatic Computation</title>
<para>If your monitor was made after 1996, it probably supports the
<ulink url="http://www.vesa.org/summary/sumeedidrar1.htm">EDID</ulink>
specification. EDID-capable monitors (sometimes called "Plug'n'Play"
monitors in Microsoft marketing literature) can report their
capabilities to your computer.</para>
<para>All modern monitors support the <ulink
url="http://www.vesa.org/summary/sumeedidrar1.htm">EDID</ulink>
specification. EDID-capable monitors report their capabilities to your
computer.</para>
<para>Many driver modules in XFree86 4.0 support DDC, the <ulink
<para>All modern X driver modules support DDC, the <ulink
url="http://www.vesa.org/dload/summary/sumeddcv1.htm">VESA Display
Data Channel facility</ulink>. A DDC-enabled graphics-card module
will ask the monitor to hand it an EDID capability description and
configure itself from that data. So with 4.0 and any recent monitor,
configure itself from that data. So with any recent monitor,
you are likely not to have to do any configuration at all.</para>
<para>If your graphics-card module happens not to be DDC-enabled but
your monitor speaks EDID, you can still use the read-edid program to
ask the monitor for its statistics and compute a mode line for you.
See the <ulink
url="http://john.fremlin.de/programs/linux/read-edid/">read-edid home
url="http://www.polypux.org/projects/read-edid/">read-edid home
page</ulink>.</para>
<para>Starting with XFree86 3.2, XFree86 provided an
<command>XF86Setup</command> program that makes it easy to generate
a working monitor mode interactively, without messing with video
timing numbers directly. So you shouldn't actually need to calculate a
base monitor mode in most cases. Unfortunately,
<command>XF86Setup</command> 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.</para>
<para>There is a KDE tool called <ulink
url="http://paranoia.rulez.org/videogen/">KVideoGen</ulink> that
computes modelines from basic monitor and card statistics. I've
experimented with generating modelines from it, but haven't tried them
in live use. 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.</para>
<para>Another XFree86 modeline generator lives <ulink
<para>A manual modeline generator lives <ulink
url="http://zaph.com/Modeline">here</ulink>. You can either download
the Python script or use the CGI form provided.</para>
<para>Recent versions of XFree86 provide a tool called
<para>X provides a tool called
<application>xvidtune</application> 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
@ -254,8 +250,8 @@ xvidtune effectively and with confidence.</para>
<para>If you have <application>xvidtune</application>(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
files or even rebooting your X server. Otherwise, X allows you
to hot-key between different modes defined in Xconfig (see X.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
<emphasis>end</emphasis> of your hot-key list. Leave a known-good
@ -273,7 +269,7 @@ better understand the relationships that define them.</para>
display<indexterm><primary>display</primary></indexterm> 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.</para>
controlling the display by the X server.</para>
<para>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
@ -415,7 +411,7 @@ clock you can use):</para>
</screen>
<para>BTW, there's nothing magic about this table; these numbers are just
the lowest dot clocks per resolution in the standard XFree86 Modes
the lowest dot clocks per resolution in the standard X 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
@ -462,9 +458,10 @@ if this were so).</para>
</sect2>
<sect2><title>The card's dot clock</title>
<para>Your video adapter manual's spec page will usually give you the card's
maximum dot clock<indexterm><primary>dot clock</primary></indexterm> (that is, the total number of pixels per second
it can write to the screen).</para>
<para>Your video adapter manual's spec page will usually give you the
card's maximum dot clock<indexterm><primary>dot
clock</primary></indexterm> (that is, the total number of pixels per
second it can write to the screen).</para>
<para>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
@ -479,7 +476,7 @@ have to reboot to get your console back.</para>
<para>The probe result or startup message should look something like one of
the following examples:</para>
<para>If you're using XFree86:</para>
<para>If you're using X.org or XFree86:</para>
<screen>
Xconfig: /usr/X11R6/lib/X11/Xconfig
@ -560,7 +557,7 @@ 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 a little beyond its rated performance. This is the design
philosophy of XFree86.</para>
philosophy of X.</para>
<para>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
@ -851,11 +848,12 @@ monitor can display at most 800x600, then high resolution is beyond
your reach anyway (see <link linkend="inter">Using Interlaced Modes</link>
for a possible remedy).</para>
<para>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).
<para>Don't worry if you have more memory than required; the X server
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.</para>
have 512,000 bytes installed, it has 512 x 1024 = 524,288
bytes.</para>
<para>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
@ -1321,7 +1319,7 @@ to the maximum pixel frequency of the board.</para>
<sect1 id="inter"><title>Using Interlaced Modes</title>
<para>(This section is largely due to David Kastrup
<email>dak@pool.informatik.rwth-aachen.de</email>)</para>
<email>dak@gnu.org</email>)</para>
<para>At a fixed dot clock, an interlaced display is going to have
considerably less noticable flicker than a non-interlaced display, if
@ -1329,7 +1327,7 @@ 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.</para>
<para>Interlaced modes got their bad reputqtion because they are inferior to
<para>Interlaced modes got their bad reputation 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
@ -1413,7 +1411,7 @@ won't promise it.</para>
</question>
<answer>
<para>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
800x600, or even 1024x768. The X server lets 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
@ -1822,8 +1820,3 @@ Local Variables:
compile-command: "mail -s \"HOWTO update\" submit@en.tldp.org <XFree86-Video-Timings-HOWTO.xml"
End:
-->
---------------------------------------------------------------------
To unsubscribe, e-mail: submit-unsubscribe@en.tldp.org
For additional commands, e-mail: submit-help@en.tldp.org