The Hitchhiker's Guide to X386/XFree86 Video Timing <subtitle>(or, Tweaking your Monitor for Fun and Profit) <author> Eric S. Raymond <em/esr@@snark.thyrsus.com/ (from an original by Chin Fang <em/fangchin@@leland.stanford.edu/; portions derive from a how-to by Bob Crosson <em/crosson@@cam.nist.gov/) <date> This is version 1.0, Jan 8th 1993. </date> <toc> <sect> Introduction Please direct comments, criticism, and suggestions for improvement to <em/esr@@snark.thyrsus.com/. The XFree86 server allows users to configure their video subsystem and thus encourages best use of existing hardware. This tutorial 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 Fixing Problems. This will enlighten you on ways to tweak the timing numbers to achieve particular effects. XFree86 allows you to hot-key between different modes defined in XF86Config (see XF86Config.man for details). Use this capability 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/ your hot-key list. Leave a known-good mode as the default to fall back on if the test mode doesn't work. The Xconfig section at the end of the second Example Calculation provides a good example of how to record your experiments in a way that will help you quickly converge on a solution. First check out the <tt/Monitors/ file in <tt>lib/X11/doc</tt> If your monitor is in it, you can probably skip the rest of this document! You may need to scale some of the timing numbers if the clock used to generate the mode in the database doesn't match what your card has available, but that's easy. <sect> How Video Displays Work Knowing how the display 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 a series of 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 beam inside the display. To make the beam strike each dot for an equal amount of time, the beam is swept across the display in a constant pattern. The pattern starts at the top left of the screen, goes across the screen to the right in a straight line, and stops temporarily on the right side of the screen. Then the beam is swept back to the left side of the display, but down one 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 beam is moved from the bottom right corner of the display to the top left corner, and the pattern is started over again. Starting the beam at the top left of the display is called the beginning of a frame. The frame ends when the beam reaches the the top left corner again as it comes from the bottom right corner of the display. A frame is made up of all of the lines the beam traced from the top of the display to the bottom. If the electron beam were on all of the time it was 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 beam is hard to control there. To reduce the distortion, the dots around the edges of the display are not illuminated by the beam even though the beam may be pointing at them. The viewable area of the display is reduced this way. Another important thing to understand is what becomes of the beam when no spot is being painted on the visible area. The time the beam would have been illuminating the side borders of the display is used for sweeping the beam back from the right edge to the left and moving the beam down to the next line. The time the beam would have been illuminating the top and bottom borders of the display is used for moving the beam 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 beam at each dot to generate a picture. The card also controls when the display moves the beam from the right side to the left and down a line 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 beam 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 beam can stabilize. If the beam can't stabilize, the picture will not be steady. 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 There are some fundamental things you need to know before hacking an Xconfig entry. These are: <enum> <item> your monitor's horizontal and vertical sync frequency options <item> your video adapter's driving clock frequency, or "dot clock" <item> your monitor's bandwidth </enum> The monitor sync frequencies: The horizontal sync frequency are 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 vertical sync frequency number is typically calibrated in Hz (cycles per second), the horizontal one in KHz (kilocycles per second). The usual ranges are between 50 and 80Hz 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 damage it. The card driving clock frequency: Your video adapter manual's spec page will usually give you the card's dot clock (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. Even if your X locks up your monitor, it will emit a line of clock and other info to standard output. If you redirect this to a file, it should be saved even if you have to reboot to get your console back. If you're using SGCS X, the line will look something like the following example, collected from a Swan local-bus S3 adapter. XFree86 uses a slightly different multi-line format. <tscreen><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></tscreen> 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. SVr4 users: the mousemgr process is particularly likely to mess you up. 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: <tscreen><verb> wga Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71 </verb></tscreen> 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! The monitor's video bandwidth: Finally, it's useful to know your monitor's video bandwidth, so you know approximately what the highest dot clock you can use is. There's a lot of give here, though --- some monitors can run as much as 30&percnt over their nominal bandwidth. Knowing the bandwidth will enable you to make more intelligent choices between possible configurations. It may affect your display's visual quality (esp. sharpness for fine details). Your monitor's video bandwidth should be included on the manual's spec page. If it's not, look at the monitor's highest 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 </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. The bandwidth of your monitor may 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 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 </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). What these control: 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. <sect> Interpreting the Basic Specifications 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'; sometimes loosely called `bandwidth'. 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 at which your monitor's video signal can change. This constrains the highest dot clock you can use and the overall sharpness of fine details in the video image. <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, *including the inactive left and right borders*. Vertical frame length (VFL) is the number of scan lines in the *entire* image, including the inactive top and bottom borders. <tag/screen refresh rate (RR)/ The number of times per second your screen is repainted. 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 *not* the same as the monitor's visible resolution, but typically somewhat larger. We'll get to the details of this below. </descrip> About Bandwidth: 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, bandwidth is mainly important as an approximate cutoff point for the highest dot clock you can use. Sync Frequencies snd the Refresh Rate: 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: <tscreen><verb> _______________________ | | The horizontal frame length |->->->->->->->->->->-> | is the time in dot clocks | )| required for the |<-----<-----<-----<--- | electron beam to trace | | a pattern like this | | | | | | |_______________________| _______________________ | ^ | The vertical frame length | ^ | | is the time in dot clocks | | v | required for the | ^ | | electron beam to trace | | | | a pattern like this | ^ | | | | v | | ^ | | |_______|_v_____________| </verb></tscreen> 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 REFRESHED per second! You need to understand this concept to design a configuration which trades off resolution against flicker in whatever way suits your needs. <sect> Tradeoffs in Configuring your System 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. You probably do not want to pull your refresh rate below 60Hz. This is the flicker rate of fluorescent lights; if you're sensitive to those, you need to hang with 72MHz, the VESA ergonomic standard. 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&percnt 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 xterm -bg white -fg black 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. 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 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 800x600, this would be 800 x 600 = 480,000, 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 are necessary on your adapter card. Thus, your memory requirement will typically be (HR * VR)/1024 Kbytes of VRAM, rounded up. In the example case, we'd need (936 * 702)/1024 = 642K. So if you have one meg, you'll have extra for virtual-screen panning. However, if you only have 512K on board, then you can't 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. 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 SGCS X 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 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 the number of horizontal sweeps per second available. 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. 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 scans per second figure 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&percnt 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. About that 4:3 --- a ratio of 4:3 for width to height of the displayed area approximates the Golden Section, (1 + sqrt(5))/2. Human beings seem to be wired to find this kind of rectangle pleasant to look at; accordingly, video tubes and the standard resolutions such as 800x600, 640x480 and 1024x768 all approximate it. Though it's psychologically magic, it's not technically magic; nothing prevents you from using a non-Golden-Section ratio if that will get the best use out of your screen real estate. 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&percnt of 944 in the example above). But before you try this "overdriving" maneuver, if you do, make *sure* 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). 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 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). Horizontal Sync: 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: <tscreen><verb> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 ^ ^ unit: ticks | ^ ^ | HR | | HFL | |<----->| | |<->| HSP |<->| HGT1 HGT2 </verb></tscreen> 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&hellip 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 concreteness 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 (= 65x10**6 * 3.8 *10**(-6)) [recall M=10**6, micro=10**(-6)] Vertical Sync: 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&percnt 8==0, (936+32)&percnt 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 lets 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 micro second long, still reasonable. In addition, 936/1232~0.76 or 76&percnt, still not far from 80&percnt, 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&percnt=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: <tscreen><verb> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 VR VFL unit: ticks ^ ^ ^ | | | |<->|<----->| VGT VSP </verb></tscreen> 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 definition 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). <sect>Putting it All Together 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 indicates at which dot the horizontal sync pulse will begin. The third field indicates at which dot the horizontal sync pulse will end. The fourth field specifies the total horizontal 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 indicates the line number at which the vertical sync pulse will begin. The third field 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 The 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. <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>Questions and Answers Q. The example you gave is not a standard screen size, can I use it? A. Why not? There is NO reason whatsoever why you have to use 640x480, 800x600, or even 1024x768. XFree86 driver lets you config your hardware with a lot of freedom. It usually takes two to three minutes 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 with 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 nothing you do can actually damage a multi-sync monitor (unless you somehow force your card to clock it at way above its bandwidth --- if you stick reasonably close to the highest resolution the monitor is documented to support this can't happen). Beware fixed-frequency monitors! This kind of hacking around *can* damage 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 employs 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 and 505. Now the refresh rate is raised to 68Hz, a quite significant improvement over the standard one. Q. But how about interlace/non-interlace? A. At a fixed dot clock, an interlaced display is going to flicker worse than a non-interlaced one, which is why the market has moved away from them. What you buy with the increased flicker is higher resolution with a slower dot clock. If the DCF were fast enough (say 90MHz or up) even interlacing wouldn't produce flicker -- but at present speeds, interlaced monitors are a bad idea for X. 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> Two More Example Calculations Here's another hypothetical: An adapter card has a 40 MHz clock rate. A display has a range of horizontal sync rates from 30 KHz to 37 KHz. The minimum number of dots per line is 40,000,000/37,000 = 1,081.081, or approximately 1,081 dots per line. We'll use this number of dots per line in the following calculations. So each line on our display must have at least 1081 dots. We round this up to 1088 to make it divisible evenly by eight. Now let's assume that the horizontal sync pulse should be 3.8 microseconds long. We need to find out how many dots it takes to make a 3.8 microsecond pulse. We do this by first finding out how many microseconds are in one dot. Since there are 40,000,000 dots per second, 1/40,000,000 is the number of seconds per dot. 1/40,000,000 = .000000025 = .025 microseconds per dot Thus the number of dots for a 3.8 microsecond sync pulse is 3.8 microseconds = D dots x .025 microseconds/dot or D dots = (3.8 microseconds) / (.025 microseconds/dot) = 152 dots So we have 1088 dots per line, 800 of which are the illuminated ones, with 152 for the sync pulse. (Note that 152 is evenly divisible by eight. If it weren't we would round it up until it was evenly divisible.) This leaves us the task of calculating the time before and after the sync pulse that is necessary for the display. The rule of thumb for this is that we need about 30 ticks of guard time. In this particular case, allocating 32 dots is convenient, because all the other quantities are divisible by 8. This results in the timing being 800 dots for the viewable area, 152 dots for the pulse, and 1088 - (800 + 152) = 136 dots to divide between the two other times. Half of 136 is 68 dots, so 68 dots are placed between the illuminated dots and the sync pulse, and 68 dots are placed after the sync pulse. The horizontal numbers in the Xconfig line then become 800 (800+68) (800+68+152) (800+68+152+68) or 800 868 1020 1088 Now we want to calculate the vertical numbers. To begin, we must remember that the vertical numbers are not in terms of dots or microseconds per dot, but are expressed as numbers of lines! So we have to calculate how much time it takes to display a single line. That's easy, because we know each line is 1088 dots and each dot is .025 microsecond. Each line is, therefore, (1088 dots/line) x (.025 microseconds/dot) = 27.2 microseconds/line Since we chose 800 visible dots per line, let's choose the number of lines to be such that the ratio of horizontal to vertical is 4 to 3. Thus, 800 is 4 x 200, so the number of visible lines should be 3 x 200 = 600. Our target resolution is 800x600. We know that a vertical sync pulse should be in the range of 50 to 300 microseconds. If we chose 150 microseconds as a typical sync pulse, we find how many lines 150 microseconds is by dividing 150 by 27.2 microseconds per line. (150 microseconds/pulse) / (27.2 microseconds/line) = 5.51 lines/pulse By rounding up (never down) to 6 lines/pulse we now have the vertical sync pulse width. To guess at the total number of lines per frame (illuminated lines plus nonilluminated lines in the border) we assume (from "Videotiming&hellip") that the total number of lines will be 5&percnt more than the number of viewable lines. So the total number of lines is (600 lines) x (1.05) = 630 total lines per frame So now we must place the pulse in the time between the end of the illuminated lines and the end of the frame. Since we have 630 total lines, 600 illuminated lines, and 6 lines for the pulse, we have 630 - 600 - 6 = 24 lines left Some displays don't mind if the pulse begins immediately after the illuminated lines, but others might want a line or two between the last illuminated line and the beginning of the sync pulse. Taking the latter course just to be safe, we add three lines between the last illuminated line and the beginning of the pulse. The rest of the lines are added after the pulse ends. So the vertical timing numbers become 600 (600+3) (600+3+6) (600+3+6+21) or 600 603 609 630 Before we do anything else, we must check that the display can handle 630 lines/frame at 27.2 microseconds/line. We do this by calculating how many frames per second our configuration will generate, and comparing it to the display manual's entry for vertical sync rate. For 630 lines/frame at 27.2 micro- seconds/line, we have 630 x 27.2 = 17,136 microseconds/frame. 17,136 microseconds/frame is 0.017136 seconds/frame, or 1/0.017892 frames/second. 1 / (0.017136 seconds/frame) = 58.4 frames/second If the manual says the vertical sync rate is 58.4 Hz, or 58.4 Hz is in the range of the display's vertical sync rate, we are fine. If the display cannot handle this rate, we'll have to change the number of lines per frame by adjusting all of the timings proportionally. Now we combine the horizontal and vertical timing numbers together with the resolution and clock values to produce a test configuration for Xconfig. Our line becomes "800x600" 40 800 868 1020 1088 600 603 609 630 Now we have a configuration of XFree86 to try. It may not work if any of our assumptions were grossly wrong, but in most cases it should at least give us a stable display. Now it takes a little experimentation to produce something pleasing. An actual calculation My adapter card has a 40 MHz crystal on it so I started with a 40 MHz clock rate. My display's maximum horizontal sync rate is 37 KHz, so the minimum dots per line are 40,000,000/37,000 = 1081. My display's vertical sync rate is the range from 50 Hz to 90 Hz. My display's manual says that the largest horizontal sync pulse is 3.92 microseconds. With 0.025 microseconds per dot, the pulse is (3.92 microseconds) / (.025 microseconds/dot) = 156.8 dots Rounding this up to the nearest number evenly divisible by eight gives 160 dots. The manual also says that the time between the last illuminated dot and the beginning of the sync pulse must be at least 0.67 microseconds. The number of dots in 0.67 microseconds at a 40 MHz clock rate - remember 40 MHz is .025 microseconds/dot - is D dots = (0.67 microseconds) / (.025 microseconds/dot) = 26.8 dots Since 26.8 is not evenly divisible by eight, round it up to 32 dots. My display's manual says the time after the sync pulse should be 3.56 microseconds or more. In dots, 3.56 microseconds is D dots = (3.56 microseconds) / (.025 microseconds/dot) = 142.4 dots Round 142.4 up to 144, so that it's evenly divisible by eight. So now for a horizontal line we have 800 illuminated dots, 32 dots between the illuminated dots and the sync pulse, 152 dots for the sync pulse, and 144 dots after the sync pulse. 800 + 32 + 160 + 144 = 1136 We now have a line that is 1136 dots long. This is greater than the 1088 we previously calculated, but remember that 1088 was the MINIMUM number of dots that could be on a line. So 1136 dots per line is okay for starters. The numbers to enter on the Xconfig line so far are "800x?" 40 800 (800+32) (800+32+160) (800+32+160+144)&hellip or "800x?" 40 800 832 992 1136&hellip A line of 1136 dots at .025 microsecond/dot means that a line represents 1136 x .025 = 28.4 microseconds. Since we chose 800 dots/line horizontal resolution, we choose 600 lines/frame as the vertical resolution. My display's manual says that the vertical sync pulse must be at least 64 microseconds long. In terms of lines, 64 microseconds is (64 microseconds/pulse) / (28.4 microseconds/line) = 2.25 lines/pulse We round 2.25 up to 3 lines for the vertical sync pulse. The manual says the time between the last displayed line and the start of the sync pulse must be at least 318 microseconds, and the delay after the end of the pulse must be at least 630 microseconds. We calculate how many lines each of these time periods represents as follows. (318 microseconds) / (28.4 microseconds/line) = 11.20 lines (630 microseconds) / (28.4 microseconds/line) = 22.18 lines We round each of the times up to become 12 lines before the sync pulse and 23 lines after the pulse. This makes our vertical timing numbers 600 (600+12) (600+12+3) (600+12+3+23) or 600 612 615 638 Checking the frame rate to see if it falls within the rate of the display, we see that 638 lines/frame at 28.4 microseconds/line is 18,119 microseconds/frame, which is 55.19 frames/second. My display can handle anything from 50 Hz to 90 Hz, so the timing is all right. Putting the resolution, clock, horizontal, vertical timing numbers together on a video mode line in Xconfig results in "800x600" 40 800 832 992 1136 600 612 615 638 This was the first video mode I tried. It turned out not to be very satisfactory because there was too much flicker. I tried other timings both above and below this setting as shown in the following example. I finally settled on the "784x614" mode as a compromise between flicker and resolution. You'll notice that almost all of the clock frequencies are 40 MHz. Through experimentation I found that higher frequencies were beyond my adapter card's capabilities, and that lower frequencies didn't provide the resolution I wanted. Example: Timings I have tried: <tscreen><verb> # the following line works but is right of center "752x564" 40 752 784 944 1088 564 567 569 611 # 44.5 752 792 976 1240 564 567 570 600 # # this line fixes the problem with the previous line #"752x564" 40 752 816 976 1088 564 567 569 611 # # trying to increase the vertical display size, it works #"752x614" 40 752 816 976 1088 614 617 619 661 # # trying to increase the horiz. display size, it works #"784x564" 40 784 816 976 1088 564 567 569 611 # # the following works but is to the right of center #"784x614" 40 784 816 976 1088 614 617 619 661 # # the following corrects the uncentered problem of the previous one "784x614" 40 784 848 1008 1088 614 617 619 661 # # trying to increase the display size # the following works, the display is slightly off center to the left #"800x614" 40 800 864 1024 1088 614 617 619 661 # # the following corrects the problem of the previous entry "800x614" 40 800 864 1024 1104 614 617 619 661 # # increase the display size, it works "816x614" 40 816 880 1040 1120 614 617 619 661 # # increase the display size, it works "800x620" 40 800 864 1024 1104 620 623 625 661 # # increase the display size, it works "816x620" 40 816 880 1040 1120 620 623 625 661 # # increase the display size, it works "832x630" 40 832 896 1056 1136 630 633 635 661 # # change the display size, it works but flickers badly "848x618" 40 848 912 1072 1152 618 621 623 661 </verb></tscreen> <sect> Fixing Problems with the Image. 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, &hellip and the image doesn't look right. What do you do? Here's a list of common problems and how to fix them. You *move* the image by changing the sync pulse timing. You *scale* 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! The image is displaced to the left or right 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. The image is displaced up or down 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. The image is too wide (too narrow) horizontally 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. The image is too deep (too shallow) vertically To fix this, decrease (increase) 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. <verb> $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.8 1996/02/04 09:08:28 dawes Exp $ $XConsortium: VidModes.sgml /main/6 1995/11/12 20:00:16 kaleb $ </verb> </article> @ 1.1 log @Initial revision @ text @@ 1.1.1.1 log @XFree86 3.2 sources @ text @@ 1.1.1.2 log @XFree86 3.3 sources. @ text @d1 1 a1 1 <!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"> d116 3 a118 3 <item>your monitor's horizontal and vertical sync frequency options <item>your video adapter's driving clock frequency, or "dot clock" <item>your monitor's bandwidth d791 1 a791 1 <item>for any fixed driving frequency, raising max resolution d795 1 a795 1 <item>if high resolution is desirable and your monitor d1149 1 a1149 1 $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.11 1997/01/25 03:22:17 dawes Exp $ d1155 1 a1155 1 $XConsortium: VidModes.sgml /main/7 1996/02/21 17:46:17 kaleb $ @ 1.1.1.3 log @XFree86 3.3.2 sources @ text @a2 4 | | |<->| HSP |<->| HGT1 HGT2 </code> d545 1 a545 1 be on the screen, covering squarely the monitor's viewable area. d550 1 a550 1 your experimentation with them equal (that is, with the sync pulse centered). d557 1 a557 1 (in fact, it's the same phenomenon at work). d560 1 a560 1 specification page. If not, here's where the real black magic starts... d564 1 a564 1 in length. d567 1 a567 1 a bad value to start with when experimenting). d570 2 a571 1 ticks (= 65 * 10**6 * 3.8 * 10^-6) [recall M=10^6, micro=10^-6] d573 1 a573 18 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 milliseconds. HAT * DCF = HR. <tag/blanking time (HBT)/ Corresponds to (HFL - HR), but in milliseconds. HBT * DCF = (HFL - HR). <tag/front porch (HFP)/ This is just HGT1. <tag/sync time/ This is just HSP. <tag/back porch (HBP)/ This is just HGT2. </descrip> <sect1>Vertical Sync: d576 1 a576 1 in the picture? d579 2 a580 2 is 1176 - 944=232 < 247! Obviously we have to do some adjustment here. What can we do? d583 1 a583 1 difference = 1184-936= 248. Hmm, closer. d589 1 a589 1 stuck? d591 3 a593 3 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. d597 2 a598 3 1232 - 32 = 1200 is also a multiple of 8 and (1232 - 32) - 968 = 232 corresponding using a sync pulse of 3.57 micro second long, still reasonable. d600 2 a601 2 In addition, 936/1232 ~ 0.76 or 76%, still not far from 80%, so it should be all right. d604 7 a610 19 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: <code> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 VR VFL unit: ticks ^ ^ ^ | | | |<->|<----->| VGT VSP </code> d612 13 d629 1 a629 1 hurt to add that. d633 1 a633 1 example, it is 1232/65Mhz=18.95us. d637 1 a637 1 ticks (150us/18.95us~8). d639 1 a639 18 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"> d645 1 a645 1 the horizontal section, and the vertical section. d650 1 a650 1 omitted if the name of a previous line is the same as the current line. d654 1 a654 1 used to generate the numbers in the following sections. d662 1 a662 1 the total horizontal frame length (HFL). d668 1 a668 1 end. The fourth field contains the total vertical frame length (VFL). d670 1 a670 1 Example: d677 2 a678 1 (Note: stock X11R5 doesn't support fractional dot clocks.) d685 3 a687 1 evenly divisible by eight. d689 1 a689 1 Example horizontal numbers: 800 864 1024 1088 d691 5 a695 4 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). d698 1 a698 1 divisible by eight! This is not required of the vertical numbers. d707 5 a711 1 the following example. d713 4 a716 1 Example vertical numbers: 600 603 609 630 d718 1 a718 3 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. d720 2 a721 1 Note that the vertical numbers don't have to be divisible by eight! a722 2 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: d724 1 a724 1 <name> DCF HR SH1 SH2 HFL VR SV1 SV2 VFL d726 1 d729 2 a730 1 its end tick. d735 1 d739 1 a739 1 <sect>Overdriving Your Monitor<label id="overd"> d742 2 a743 125 You should absolutely not 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. (Note: the theoretical limit of discernible 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.) 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. 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. 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"> (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 noticeable 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 refresh rate (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 jump 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 unsatisfactory flickery or washed out (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"> Q. The example you gave is not a standard screen size, can I use it? d746 4 a749 5 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! d751 2 a752 1 Q. It this the only resolution given the 65Mhz dot clock and 55Khz HSF? d755 1 a755 1 do some trial-and-error to come up a setting that's really to your liking. d757 6 a762 7 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 every experiment on them. d766 1 a766 1 tinkering with timings? d774 3 a776 1 quite significant improvement over the standard one. d778 7 a784 1 Q. Can you summarize what we have discussed so far? d786 3 a788 1 A. In a nutshell: d791 8 a798 7 <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! d801 1 a801 1 <sect>Fixing Problems with the Image.<label id="fixes"> d803 50 d854 117 a970 4 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 problems and how to fix them. d972 1 a972 1 (Fixing these minor distortions is where <bf>xvidtune</bf>(1) really shines.) d974 1 a974 4 You move the image by changing the sync pulse timing. You scale 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: d976 1 a976 7 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! d978 1 a978 2 <sect1>The image is displaced to the left or right a979 3 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. d981 2 a982 3 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. d984 2 a985 2 <sect1>The image is displaced up or down d987 3 a989 7 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. d991 2 a992 2 <sect1>The image is too large both horizontally and vertically d994 1 a994 2 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. d996 5 a1000 2 <sect1>The image is too wide (too narrow) horizontally d1002 2 a1003 4 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. d1005 2 a1006 2 <sect1>The image is too deep (too shallow) vertically d1008 3 a1010 4 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. d1012 1 a1012 3 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. d1014 1 a1014 2 Finally, remember that increasing either frame length will decrease your refresh rate, and vice-versa. d1016 1 a1016 2 <sect>Plotting Monitor Capabilities<label id="cplot"> d1018 5 a1022 117 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 modeplot: <code> #!/bin/sh # # modeplot -- generate X mode plot of available monitor modes # # Do `modeplot -?' to see the control options. # # ($Id: video-modes.sgml,v 1.2 1997/08/08 15:07:24 esr Exp $) # 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.2 $ 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 </code> 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: d1024 2 a1025 6 <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: d1027 1 a1027 5 <tscreen><verb> HFL = F1 * HR VFL = F2 * VR </verb></tscreen> </enum> d1029 5 a1033 2 As a rough guide, take F1 = 1.30 and F2 = 1.05 (see <ref id=frame> "Computing Frame Sizes"). d1035 4 a1038 4 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. d1040 2 a1041 2 The refresh rate is equal to the clock rate divided by the product of the frame sizes: d1044 40 a1083 1 RR = DCF / (HFL * VFL) (*) d1086 2 a1087 2 On the other hand, the horizontal frame length is equal to the clock rate divided by the horizontal sync frequency: d1089 4 a1092 3 <tscreen><verb> HFL = DCF / HSF (**) </verb></tscreen> d1094 4 a1097 1 VFL can be reduced to HFL be means of the two assumptions above: d1099 9 a1107 5 <tscreen><verb> VFL = F2 * VR = F2 * (HR / AR) = (F2/F1) * HFL / AR (***) </verb></tscreen> d1109 3 a1111 1 Inserting (**) and (***) into (*) we obtain: d1113 3 a1115 5 <tscreen><verb> RR = DCF / ((F2/F1) * HFL**2 / AR) = (F1/F2) * AR * DCF * (HSF/DCF)**2 = (F1/F2) * AR * HSF**2 / DCF </verb></tscreen> d1117 1 a1117 3 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. d1119 3 a1121 2 The straight lines crossing the capability region represent particular resolutions. This is based on (*) and the second assumption: d1123 3 a1125 3 <tscreen><verb> RR = DCF / (HFL * VFL) = DCF / (F1 * HR * F2 * VR) </verb></tscreen> d1127 1 a1127 9 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: d1129 4 a1132 3 <tscreen><verb> modeplot -t "Swan SW617" -b 85 -v 50 90 -h 31 58 </verb></tscreen> d1134 1 a1134 2 The -b option specifies video bandwidth; -v and -h set horizontal and vertical sync frequency ranges. d1136 4 a1139 8 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. d1141 3 a1143 2 <sect>Credits<label id="credi"> d1145 2 a1146 2 The original ancestor of this document was by Chin Fang <fangchin@@leland.stanford.edu>. a1147 13 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> 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. d1149 6 a1154 6 $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.11.2.2 1998/02/20 23:10:30 dawes Exp $ d1157 1 a1157 1 a1158 8 <!-- The following sets edit modes for GNU EMACS Local Variables: fill-prefix:"\t" fill-column:75 End: --

The Hitchhiker's Guide to X386/XFree86 Video Timing <subtitle>(or, Tweaking your Monitor for Fun and Profit) <author> Eric S. Raymond <em/esr@@snark.thyrsus.com/ (from an original by Chin Fang <em/fangchin@@leland.stanford.edu/; portions derive from a how-to by Bob Crosson <em/crosson@@cam.nist.gov/) <date> This is version 1.0, Jan 8th 1993. </date> <toc> <sect> Introduction Please direct comments, criticism, and suggestions for improvement to <em/esr@@snark.thyrsus.com/. The XFree86 server allows users to configure their video subsystem and thus encourages best use of existing hardware. This tutorial 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 Fixing Problems. This will enlighten you on ways to tweak the timing numbers to achieve particular effects. XFree86 allows you to hot-key between different modes defined in XF86Config (see XF86Config.man for details). Use this capability 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/ your hot-key list. Leave a known-good mode as the default to fall back on if the test mode doesn't work. The Xconfig section at the end of the second Example Calculation provides a good example of how to record your experiments in a way that will help you quickly converge on a solution. First check out the <tt/Monitors/ file in <tt>lib/X11/doc</tt> If your monitor is in it, you can probably skip the rest of this document! You may need to scale some of the timing numbers if the clock used to generate the mode in the database doesn't match what your card has available, but that's easy. <sect> How Video Displays Work Knowing how the display 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 a series of 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 beam inside the display. To make the beam strike each dot for an equal amount of time, the beam is swept across the display in a constant pattern. The pattern starts at the top left of the screen, goes across the screen to the right in a straight line, and stops temporarily on the right side of the screen. Then the beam is swept back to the left side of the display, but down one 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 beam is moved from the bottom right corner of the display to the top left corner, and the pattern is started over again. Starting the beam at the top left of the display is called the beginning of a frame. The frame ends when the beam reaches the the top left corner again as it comes from the bottom right corner of the display. A frame is made up of all of the lines the beam traced from the top of the display to the bottom. If the electron beam were on all of the time it was 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 beam is hard to control there. To reduce the distortion, the dots around the edges of the display are not illuminated by the beam even though the beam may be pointing at them. The viewable area of the display is reduced this way. Another important thing to understand is what becomes of the beam when no spot is being painted on the visible area. The time the beam would have been illuminating the side borders of the display is used for sweeping the beam back from the right edge to the left and moving the beam down to the next line. The time the beam would have been illuminating the top and bottom borders of the display is used for moving the beam 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 beam at each dot to generate a picture. The card also controls when the display moves the beam from the right side to the left and down a line 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 beam 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 beam can stabilize. If the beam can't stabilize, the picture will not be steady. 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 There are some fundamental things you need to know before hacking an Xconfig entry. These are: <enum> <item> your monitor's horizontal and vertical sync frequency options <item> your video adapter's driving clock frequency, or "dot clock" <item> your monitor's bandwidth </enum> The monitor sync frequencies: The horizontal sync frequency are 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 vertical sync frequency number is typically calibrated in Hz (cycles per second), the horizontal one in KHz (kilocycles per second). The usual ranges are between 50 and 80Hz 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 damage it. The card driving clock frequency: Your video adapter manual's spec page will usually give you the card's dot clock (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. Even if your X locks up your monitor, it will emit a line of clock and other info to standard output. If you redirect this to a file, it should be saved even if you have to reboot to get your console back. If you're using SGCS X, the line will look something like the following example, collected from a Swan local-bus S3 adapter. XFree86 uses a slightly different multi-line format. <tscreen><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></tscreen> 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. SVr4 users: the mousemgr process is particularly likely to mess you up. 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: <tscreen><verb> wga Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71 </verb></tscreen> 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! The monitor's video bandwidth: Finally, it's useful to know your monitor's video bandwidth, so you know approximately what the highest dot clock you can use is. There's a lot of give here, though --- some monitors can run as much as 30&percnt over their nominal bandwidth. Knowing the bandwidth will enable you to make more intelligent choices between possible configurations. It may affect your display's visual quality (esp. sharpness for fine details). Your monitor's video bandwidth should be included on the manual's spec page. If it's not, look at the monitor's highest 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 </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. The bandwidth of your monitor may 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 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 </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). What these control: 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. <sect> Interpreting the Basic Specifications 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'; sometimes loosely called `bandwidth'. 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 at which your monitor's video signal can change. This constrains the highest dot clock you can use and the overall sharpness of fine details in the video image. <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, *including the inactive left and right borders*. Vertical frame length (VFL) is the number of scan lines in the *entire* image, including the inactive top and bottom borders. <tag/screen refresh rate (RR)/ The number of times per second your screen is repainted. 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 *not* the same as the monitor's visible resolution, but typically somewhat larger. We'll get to the details of this below. </descrip> About Bandwidth: 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, bandwidth is mainly important as an approximate cutoff point for the highest dot clock you can use. Sync Frequencies snd the Refresh Rate: 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: <tscreen><verb> _______________________ | | The horizontal frame length |->->->->->->->->->->-> | is the time in dot clocks | )| required for the |<-----<-----<-----<--- | electron beam to trace | | a pattern like this | | | | | | |_______________________| _______________________ | ^ | The vertical frame length | ^ | | is the time in dot clocks | | v | required for the | ^ | | electron beam to trace | | | | a pattern like this | ^ | | | | v | | ^ | | |_______|_v_____________| </verb></tscreen> 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 REFRESHED per second! You need to understand this concept to design a configuration which trades off resolution against flicker in whatever way suits your needs. <sect> Tradeoffs in Configuring your System 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. You probably do not want to pull your refresh rate below 60Hz. This is the flicker rate of fluorescent lights; if you're sensitive to those, you need to hang with 72MHz, the VESA ergonomic standard. 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&percnt 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 xterm -bg white -fg black 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. 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 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 800x600, this would be 800 x 600 = 480,000, 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 are necessary on your adapter card. Thus, your memory requirement will typically be (HR * VR)/1024 Kbytes of VRAM, rounded up. In the example case, we'd need (936 * 702)/1024 = 642K. So if you have one meg, you'll have extra for virtual-screen panning. However, if you only have 512K on board, then you can't 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. 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 SGCS X 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 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 the number of horizontal sweeps per second available. 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. 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 scans per second figure 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&percnt 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. About that 4:3 --- a ratio of 4:3 for width to height of the displayed area approximates the Golden Section, (1 + sqrt(5))/2. Human beings seem to be wired to find this kind of rectangle pleasant to look at; accordingly, video tubes and the standard resolutions such as 800x600, 640x480 and 1024x768 all approximate it. Though it's psychologically magic, it's not technically magic; nothing prevents you from using a non-Golden-Section ratio if that will get the best use out of your screen real estate. 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&percnt of 944 in the example above). But before you try this "overdriving" maneuver, if you do, make *sure* 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). 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 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). Horizontal Sync: 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: <tscreen><verb> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 ^ ^ unit: ticks | ^ ^ | HR | | HFL | |<----->| | |<->| HSP |<->| HGT1 HGT2 </verb></tscreen> 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&hellip 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 concreteness 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 (= 65x10**6 * 3.8 *10**(-6)) [recall M=10**6, micro=10**(-6)] Vertical Sync: 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&percnt 8==0, (936+32)&percnt 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 lets 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 micro second long, still reasonable. In addition, 936/1232~0.76 or 76&percnt, still not far from 80&percnt, 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&percnt=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: <tscreen><verb> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 VR VFL unit: ticks ^ ^ ^ | | | |<->|<----->| VGT VSP </verb></tscreen> 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 definition 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). <sect>Putting it All Together 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 indicates at which dot the horizontal sync pulse will begin. The third field indicates at which dot the horizontal sync pulse will end. The fourth field specifies the total horizontal 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 indicates the line number at which the vertical sync pulse will begin. The third field 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 The 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. <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>Questions and Answers Q. The example you gave is not a standard screen size, can I use it? A. Why not? There is NO reason whatsoever why you have to use 640x480, 800x600, or even 1024x768. XFree86 driver lets you config your hardware with a lot of freedom. It usually takes two to three minutes 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 with 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 nothing you do can actually damage a multi-sync monitor (unless you somehow force your card to clock it at way above its bandwidth --- if you stick reasonably close to the highest resolution the monitor is documented to support this can't happen). Beware fixed-frequency monitors! This kind of hacking around *can* damage 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 employs 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 and 505. Now the refresh rate is raised to 68Hz, a quite significant improvement over the standard one. Q. But how about interlace/non-interlace? A. At a fixed dot clock, an interlaced display is going to flicker worse than a non-interlaced one, which is why the market has moved away from them. What you buy with the increased flicker is higher resolution with a slower dot clock. If the DCF were fast enough (say 90MHz or up) even interlacing wouldn't produce flicker -- but at present speeds, interlaced monitors are a bad idea for X. 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> Two More Example Calculations Here's another hypothetical: An adapter card has a 40 MHz clock rate. A display has a range of horizontal sync rates from 30 KHz to 37 KHz. The minimum number of dots per line is 40,000,000/37,000 = 1,081.081, or approximately 1,081 dots per line. We'll use this number of dots per line in the following calculations. So each line on our display must have at least 1081 dots. We round this up to 1088 to make it divisible evenly by eight. Now let's assume that the horizontal sync pulse should be 3.8 microseconds long. We need to find out how many dots it takes to make a 3.8 microsecond pulse. We do this by first finding out how many microseconds are in one dot. Since there are 40,000,000 dots per second, 1/40,000,000 is the number of seconds per dot. 1/40,000,000 = .000000025 = .025 microseconds per dot Thus the number of dots for a 3.8 microsecond sync pulse is 3.8 microseconds = D dots x .025 microseconds/dot or D dots = (3.8 microseconds) / (.025 microseconds/dot) = 152 dots So we have 1088 dots per line, 800 of which are the illuminated ones, with 152 for the sync pulse. (Note that 152 is evenly divisible by eight. If it weren't we would round it up until it was evenly divisible.) This leaves us the task of calculating the time before and after the sync pulse that is necessary for the display. The rule of thumb for this is that we need about 30 ticks of guard time. In this particular case, allocating 32 dots is convenient, because all the other quantities are divisible by 8. This results in the timing being 800 dots for the viewable area, 152 dots for the pulse, and 1088 - (800 + 152) = 136 dots to divide between the two other times. Half of 136 is 68 dots, so 68 dots are placed between the illuminated dots and the sync pulse, and 68 dots are placed after the sync pulse. The horizontal numbers in the Xconfig line then become 800 (800+68) (800+68+152) (800+68+152+68) or 800 868 1020 1088 Now we want to calculate the vertical numbers. To begin, we must remember that the vertical numbers are not in terms of dots or microseconds per dot, but are expressed as numbers of lines! So we have to calculate how much time it takes to display a single line. That's easy, because we know each line is 1088 dots and each dot is .025 microsecond. Each line is, therefore, (1088 dots/line) x (.025 microseconds/dot) = 27.2 microseconds/line Since we chose 800 visible dots per line, let's choose the number of lines to be such that the ratio of horizontal to vertical is 4 to 3. Thus, 800 is 4 x 200, so the number of visible lines should be 3 x 200 = 600. Our target resolution is 800x600. We know that a vertical sync pulse should be in the range of 50 to 300 microseconds. If we chose 150 microseconds as a typical sync pulse, we find how many lines 150 microseconds is by dividing 150 by 27.2 microseconds per line. (150 microseconds/pulse) / (27.2 microseconds/line) = 5.51 lines/pulse By rounding up (never down) to 6 lines/pulse we now have the vertical sync pulse width. To guess at the total number of lines per frame (illuminated lines plus nonilluminated lines in the border) we assume (from "Videotiming&hellip") that the total number of lines will be 5&percnt more than the number of viewable lines. So the total number of lines is (600 lines) x (1.05) = 630 total lines per frame So now we must place the pulse in the time between the end of the illuminated lines and the end of the frame. Since we have 630 total lines, 600 illuminated lines, and 6 lines for the pulse, we have 630 - 600 - 6 = 24 lines left Some displays don't mind if the pulse begins immediately after the illuminated lines, but others might want a line or two between the last illuminated line and the beginning of the sync pulse. Taking the latter course just to be safe, we add three lines between the last illuminated line and the beginning of the pulse. The rest of the lines are added after the pulse ends. So the vertical timing numbers become 600 (600+3) (600+3+6) (600+3+6+21) or 600 603 609 630 Before we do anything else, we must check that the display can handle 630 lines/frame at 27.2 microseconds/line. We do this by calculating how many frames per second our configuration will generate, and comparing it to the display manual's entry for vertical sync rate. For 630 lines/frame at 27.2 micro- seconds/line, we have 630 x 27.2 = 17,136 microseconds/frame. 17,136 microseconds/frame is 0.017136 seconds/frame, or 1/0.017892 frames/second. 1 / (0.017136 seconds/frame) = 58.4 frames/second If the manual says the vertical sync rate is 58.4 Hz, or 58.4 Hz is in the range of the display's vertical sync rate, we are fine. If the display cannot handle this rate, we'll have to change the number of lines per frame by adjusting all of the timings proportionally. Now we combine the horizontal and vertical timing numbers together with the resolution and clock values to produce a test configuration for Xconfig. Our line becomes "800x600" 40 800 868 1020 1088 600 603 609 630 Now we have a configuration of XFree86 to try. It may not work if any of our assumptions were grossly wrong, but in most cases it should at least give us a stable display. Now it takes a little experimentation to produce something pleasing. An actual calculation My adapter card has a 40 MHz crystal on it so I started with a 40 MHz clock rate. My display's maximum horizontal sync rate is 37 KHz, so the minimum dots per line are 40,000,000/37,000 = 1081. My display's vertical sync rate is the range from 50 Hz to 90 Hz. My display's manual says that the largest horizontal sync pulse is 3.92 microseconds. With 0.025 microseconds per dot, the pulse is (3.92 microseconds) / (.025 microseconds/dot) = 156.8 dots Rounding this up to the nearest number evenly divisible by eight gives 160 dots. The manual also says that the time between the last illuminated dot and the beginning of the sync pulse must be at least 0.67 microseconds. The number of dots in 0.67 microseconds at a 40 MHz clock rate - remember 40 MHz is .025 microseconds/dot - is D dots = (0.67 microseconds) / (.025 microseconds/dot) = 26.8 dots Since 26.8 is not evenly divisible by eight, round it up to 32 dots. My display's manual says the time after the sync pulse should be 3.56 microseconds or more. In dots, 3.56 microseconds is D dots = (3.56 microseconds) / (.025 microseconds/dot) = 142.4 dots Round 142.4 up to 144, so that it's evenly divisible by eight. So now for a horizontal line we have 800 illuminated dots, 32 dots between the illuminated dots and the sync pulse, 152 dots for the sync pulse, and 144 dots after the sync pulse. 800 + 32 + 160 + 144 = 1136 We now have a line that is 1136 dots long. This is greater than the 1088 we previously calculated, but remember that 1088 was the MINIMUM number of dots that could be on a line. So 1136 dots per line is okay for starters. The numbers to enter on the Xconfig line so far are "800x?" 40 800 (800+32) (800+32+160) (800+32+160+144)&hellip or "800x?" 40 800 832 992 1136&hellip A line of 1136 dots at .025 microsecond/dot means that a line represents 1136 x .025 = 28.4 microseconds. Since we chose 800 dots/line horizontal resolution, we choose 600 lines/frame as the vertical resolution. My display's manual says that the vertical sync pulse must be at least 64 microseconds long. In terms of lines, 64 microseconds is (64 microseconds/pulse) / (28.4 microseconds/line) = 2.25 lines/pulse We round 2.25 up to 3 lines for the vertical sync pulse. The manual says the time between the last displayed line and the start of the sync pulse must be at least 318 microseconds, and the delay after the end of the pulse must be at least 630 microseconds. We calculate how many lines each of these time periods represents as follows. (318 microseconds) / (28.4 microseconds/line) = 11.20 lines (630 microseconds) / (28.4 microseconds/line) = 22.18 lines We round each of the times up to become 12 lines before the sync pulse and 23 lines after the pulse. This makes our vertical timing numbers 600 (600+12) (600+12+3) (600+12+3+23) or 600 612 615 638 Checking the frame rate to see if it falls within the rate of the display, we see that 638 lines/frame at 28.4 microseconds/line is 18,119 microseconds/frame, which is 55.19 frames/second. My display can handle anything from 50 Hz to 90 Hz, so the timing is all right. Putting the resolution, clock, horizontal, vertical timing numbers together on a video mode line in Xconfig results in "800x600" 40 800 832 992 1136 600 612 615 638 This was the first video mode I tried. It turned out not to be very satisfactory because there was too much flicker. I tried other timings both above and below this setting as shown in the following example. I finally settled on the "784x614" mode as a compromise between flicker and resolution. You'll notice that almost all of the clock frequencies are 40 MHz. Through experimentation I found that higher frequencies were beyond my adapter card's capabilities, and that lower frequencies didn't provide the resolution I wanted. Example: Timings I have tried: <tscreen><verb> # the following line works but is right of center "752x564" 40 752 784 944 1088 564 567 569 611 # 44.5 752 792 976 1240 564 567 570 600 # # this line fixes the problem with the previous line #"752x564" 40 752 816 976 1088 564 567 569 611 # # trying to increase the vertical display size, it works #"752x614" 40 752 816 976 1088 614 617 619 661 # # trying to increase the horiz. display size, it works #"784x564" 40 784 816 976 1088 564 567 569 611 # # the following works but is to the right of center #"784x614" 40 784 816 976 1088 614 617 619 661 # # the following corrects the uncentered problem of the previous one "784x614" 40 784 848 1008 1088 614 617 619 661 # # trying to increase the display size # the following works, the display is slightly off center to the left #"800x614" 40 800 864 1024 1088 614 617 619 661 # # the following corrects the problem of the previous entry "800x614" 40 800 864 1024 1104 614 617 619 661 # # increase the display size, it works "816x614" 40 816 880 1040 1120 614 617 619 661 # # increase the display size, it works "800x620" 40 800 864 1024 1104 620 623 625 661 # # increase the display size, it works "816x620" 40 816 880 1040 1120 620 623 625 661 # # increase the display size, it works "832x630" 40 832 896 1056 1136 630 633 635 661 # # change the display size, it works but flickers badly "848x618" 40 848 912 1072 1152 618 621 623 661 </verb></tscreen> <sect> Fixing Problems with the Image. 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, &hellip and the image doesn't look right. What do you do? Here's a list of common problems and how to fix them. You *move* the image by changing the sync pulse timing. You *scale* 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! The image is displaced to the left or right 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. The image is displaced up or down 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. The image is too wide (too narrow) horizontally 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. The image is too deep (too shallow) vertically To fix this, decrease (increase) 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. <verb> $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.8 1996/02/04 09:08:28 dawes Exp $ $XConsortium: VidModes.sgml /main/6 1995/11/12 20:00:16 kaleb $ </verb> </article> @ 1.1 log @Initial revision @ text @@ 1.1.1.1 log @XFree86 3.2 sources @ text @@ 1.1.1.2 log @XFree86 3.3 sources. @ text @d1 1 a1 1 <!DOCTYPE linuxdoc PUBLIC "-//XFree86//DTD linuxdoc//EN"> d116 3 a118 3 <item>your monitor's horizontal and vertical sync frequency options <item>your video adapter's driving clock frequency, or "dot clock" <item>your monitor's bandwidth d791 1 a791 1 <item>for any fixed driving frequency, raising max resolution d795 1 a795 1 <item>if high resolution is desirable and your monitor d1149 1 a1149 1 $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.11 1997/01/25 03:22:17 dawes Exp $ d1155 1 a1155 1 $XConsortium: VidModes.sgml /main/7 1996/02/21 17:46:17 kaleb $ @ 1.1.1.3 log @XFree86 3.3.2 sources @ text @a2 4 | | |<->| HSP |<->| HGT1 HGT2 </code> d545 1 a545 1 be on the screen, covering squarely the monitor's viewable area. d550 1 a550 1 your experimentation with them equal (that is, with the sync pulse centered). d557 1 a557 1 (in fact, it's the same phenomenon at work). d560 1 a560 1 specification page. If not, here's where the real black magic starts... d564 1 a564 1 in length. d567 1 a567 1 a bad value to start with when experimenting). d570 2 a571 1 ticks (= 65 * 10**6 * 3.8 * 10^-6) [recall M=10^6, micro=10^-6] d573 1 a573 18 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 milliseconds. HAT * DCF = HR. <tag/blanking time (HBT)/ Corresponds to (HFL - HR), but in milliseconds. HBT * DCF = (HFL - HR). <tag/front porch (HFP)/ This is just HGT1. <tag/sync time/ This is just HSP. <tag/back porch (HBP)/ This is just HGT2. </descrip> <sect1>Vertical Sync: d576 1 a576 1 in the picture? d579 2 a580 2 is 1176 - 944=232 < 247! Obviously we have to do some adjustment here. What can we do? d583 1 a583 1 difference = 1184-936= 248. Hmm, closer. d589 1 a589 1 stuck? d591 3 a593 3 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. d597 2 a598 3 1232 - 32 = 1200 is also a multiple of 8 and (1232 - 32) - 968 = 232 corresponding using a sync pulse of 3.57 micro second long, still reasonable. d600 2 a601 2 In addition, 936/1232 ~ 0.76 or 76%, still not far from 80%, so it should be all right. d604 7 a610 19 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: <code> |___ __ __ __ __ __ __ __ __ __ __ __ __ |_ _ _ _ _ _ _ _ _ _ _ _ | |_______________________|_______________|_____ 0 VR VFL unit: ticks ^ ^ ^ | | | |<->|<----->| VGT VSP </code> d612 13 d629 1 a629 1 hurt to add that. d633 1 a633 1 example, it is 1232/65Mhz=18.95us. d637 1 a637 1 ticks (150us/18.95us~8). d639 1 a639 18 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"> d645 1 a645 1 the horizontal section, and the vertical section. d650 1 a650 1 omitted if the name of a previous line is the same as the current line. d654 1 a654 1 used to generate the numbers in the following sections. d662 1 a662 1 the total horizontal frame length (HFL). d668 1 a668 1 end. The fourth field contains the total vertical frame length (VFL). d670 1 a670 1 Example: d677 2 a678 1 (Note: stock X11R5 doesn't support fractional dot clocks.) d685 3 a687 1 evenly divisible by eight. d689 1 a689 1 Example horizontal numbers: 800 864 1024 1088 d691 5 a695 4 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). d698 1 a698 1 divisible by eight! This is not required of the vertical numbers. d707 5 a711 1 the following example. d713 4 a716 1 Example vertical numbers: 600 603 609 630 d718 1 a718 3 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. d720 2 a721 1 Note that the vertical numbers don't have to be divisible by eight! a722 2 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: d724 1 a724 1 <name> DCF HR SH1 SH2 HFL VR SV1 SV2 VFL d726 1 d729 2 a730 1 its end tick. d735 1 d739 1 a739 1 <sect>Overdriving Your Monitor<label id="overd"> d742 2 a743 125 You should absolutely not 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. (Note: the theoretical limit of discernible 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.) 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. 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. 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"> (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 noticeable 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 refresh rate (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 jump 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 unsatisfactory flickery or washed out (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"> Q. The example you gave is not a standard screen size, can I use it? d746 4 a749 5 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! d751 2 a752 1 Q. It this the only resolution given the 65Mhz dot clock and 55Khz HSF? d755 1 a755 1 do some trial-and-error to come up a setting that's really to your liking. d757 6 a762 7 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 every experiment on them. d766 1 a766 1 tinkering with timings? d774 3 a776 1 quite significant improvement over the standard one. d778 7 a784 1 Q. Can you summarize what we have discussed so far? d786 3 a788 1 A. In a nutshell: d791 8 a798 7 <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! d801 1 a801 1 <sect>Fixing Problems with the Image.<label id="fixes"> d803 50 d854 117 a970 4 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 problems and how to fix them. d972 1 a972 1 (Fixing these minor distortions is where <bf>xvidtune</bf>(1) really shines.) d974 1 a974 4 You move the image by changing the sync pulse timing. You scale 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: d976 1 a976 7 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! d978 1 a978 2 <sect1>The image is displaced to the left or right a979 3 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. d981 2 a982 3 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. d984 2 a985 2 <sect1>The image is displaced up or down d987 3 a989 7 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. d991 2 a992 2 <sect1>The image is too large both horizontally and vertically d994 1 a994 2 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. d996 5 a1000 2 <sect1>The image is too wide (too narrow) horizontally d1002 2 a1003 4 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. d1005 2 a1006 2 <sect1>The image is too deep (too shallow) vertically d1008 3 a1010 4 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. d1012 1 a1012 3 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. d1014 1 a1014 2 Finally, remember that increasing either frame length will decrease your refresh rate, and vice-versa. d1016 1 a1016 2 <sect>Plotting Monitor Capabilities<label id="cplot"> d1018 5 a1022 117 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 modeplot: <code> #!/bin/sh # # modeplot -- generate X mode plot of available monitor modes # # Do `modeplot -?' to see the control options. # # ($Id: video-modes.sgml,v 1.2 1997/08/08 15:07:24 esr Exp $) # 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.2 $ 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 </code> 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: d1024 2 a1025 6 <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: d1027 1 a1027 5 <tscreen><verb> HFL = F1 * HR VFL = F2 * VR </verb></tscreen> </enum> d1029 5 a1033 2 As a rough guide, take F1 = 1.30 and F2 = 1.05 (see <ref id=frame> "Computing Frame Sizes"). d1035 4 a1038 4 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. d1040 2 a1041 2 The refresh rate is equal to the clock rate divided by the product of the frame sizes: d1044 40 a1083 1 RR = DCF / (HFL * VFL) (*) d1086 2 a1087 2 On the other hand, the horizontal frame length is equal to the clock rate divided by the horizontal sync frequency: d1089 4 a1092 3 <tscreen><verb> HFL = DCF / HSF (**) </verb></tscreen> d1094 4 a1097 1 VFL can be reduced to HFL be means of the two assumptions above: d1099 9 a1107 5 <tscreen><verb> VFL = F2 * VR = F2 * (HR / AR) = (F2/F1) * HFL / AR (***) </verb></tscreen> d1109 3 a1111 1 Inserting (**) and (***) into (*) we obtain: d1113 3 a1115 5 <tscreen><verb> RR = DCF / ((F2/F1) * HFL**2 / AR) = (F1/F2) * AR * DCF * (HSF/DCF)**2 = (F1/F2) * AR * HSF**2 / DCF </verb></tscreen> d1117 1 a1117 3 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. d1119 3 a1121 2 The straight lines crossing the capability region represent particular resolutions. This is based on (*) and the second assumption: d1123 3 a1125 3 <tscreen><verb> RR = DCF / (HFL * VFL) = DCF / (F1 * HR * F2 * VR) </verb></tscreen> d1127 1 a1127 9 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: d1129 4 a1132 3 <tscreen><verb> modeplot -t "Swan SW617" -b 85 -v 50 90 -h 31 58 </verb></tscreen> d1134 1 a1134 2 The -b option specifies video bandwidth; -v and -h set horizontal and vertical sync frequency ranges. d1136 4 a1139 8 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. d1141 3 a1143 2 <sect>Credits<label id="credi"> d1145 2 a1146 2 The original ancestor of this document was by Chin Fang <fangchin@@leland.stanford.edu>. a1147 13 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> 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. d1149 6 a1154 6 $XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/VidModes.sgml,v 3.11.2.2 1998/02/20 23:10:30 dawes Exp $ d1157 1 a1157 1 a1158 8 <!-- The following sets edit modes for GNU EMACS Local Variables: fill-prefix:"\t" fill-column:75 End: -- > @