If your web browser formats this page incorrectly, try viewing the page source. In netscape 4, click the view menu, then click page source. You define a video mode for X windows by setting the clock speed of your display controller and the number of clock ticks for each of several things, like this: Modeline "640x480" 25.175 640 664 760 800 480 491 493 525 "640x480" is the name of the video mode. In this case the name describes the video mode; if you have more than one video mode, this makes it easier for you to remember which video mode is which. But if are testing many video modes, it is probably easier to name your video modes "a", "b", "c", etc. 25.175 is the display controller clock speed; when you use this video mode the X server will set your display controller to this clock speed. This number is in megahertz; 25.175 means 25,175,000 clock ticks per second. Display controllers send one pixel for each clock tick. Pixels may be called dots. The display controller clock speed may be called the dot clock, because it sends that many dots per second. 640 is the clock tick count at which the display controller stops sending pixels to the display for the current horizontal line. The display controller starts sending pixels at a count of 0, and it writes 1 pixel for each clock tick; therefore 640 is the number of visible pixels per horizontal line. 664 is the clock tick count at which to start sending the horizontal synchronization pulse. 760 is the clock tick count at which to stop sending the horizontal synchronization pulse. 800 is the clock tick count at which to reset the clock tick counter to 0, and to add 1 to the line counter. When the clock tick counter is reset to 0, the display controller starts the next horizontal line; therefore 800 is the total number of clock ticks per horizontal line. 480 is the line count at which to stop sending visible lines to the display. Since the display controller starts sending visible lines to the display at a line count of 0, 480 is the number of visible lines. Some people prefer to say that 480 is the number of pixels per vertical line. 491 is the line count at which to start sending the vertical synchronization pulse. 493 is the line count at which to stop sending the vertical synchronization pulse. 525 is the line count at which to reset the line counter to 0. When the line counter is reset to 0, the display controller starts the next screen; therefore 525 is the total number of lines. To calculate the numbers for a fixed frequency display: Modeline name speed t1 t2 t3 t4 l1 l2 l3 l4 Pick a clock speed and a horizontal synchronization frequency. Note that many display controllers require that t1, t2, t3, and t4 be multiples of 8; therefore after you calculate these numbers you may want to round them to the nearest multiple of 8. If you do not know if your display controller requires multiples of 8, assume that it requires multiples of 8. t4 is the total number of clock ticks per horizontal line. Calculate it by dividing the display controller clock speed by the horizontal synchronization frequency. If the clock speed is 25,175,000 ticks per second and the horizontal synchronization frequency is 31,500 pulses per second, then t4 is 799.2. You need to round t4 to the nearest whole number, maybe to a multiple of 8. Therefore t4 should be 800. t1 is the number of visible pixels per horizontal line. t1 is usually about 82 percent of t4. Therefore t1 equals t4 multiplied by .82, rounded to the nearest whole number, maybe rounded to a multiple of 8. If t4 equals 800, t1 is 656. (However, you may wish to use some number other than .82. A higher number results in better resolution and/or better synchronization frequencies, but a lower number is more likely to work. The standard recommendation is .80; I actually use .83.) For t2, add about 8 to t1. For t3, add about 80 to t2. l1 is the number of visible lines, or the number of visible pixels per vertical line. Most displays have a height which is 75 percent of the width; multiply t1 by .75 to get l1, then round l1 to the nearest whole number. For example, if t1 is 656, then l1 is 492. For l2, add about 1 to l1 For l3, add about 3 to l2 l1 is usually about 95 percent of l4. Therefore l4 equals l1 divided by .95, rounded to the nearest whole number. If l1 is 492, then l4 is 518. (However, you may wish to use some number other than .95. A larger number results in better resolution and/or better synchronization frequencies; a lower number is more likely to work. The standard recommendation is .95. I actually use .96.) horizontal display total number of synchronization = controller divide clock ticks per frequency clock speed by horizontal line vertical horizontal total number synchronization = synchronization divide of horizontal frequency frequency by lines The horizontal synchronization frequency may also be called the horizontal refresh rate or the horizontal scan frequency. The vertical sychronization frequency may also be called the refresh rate or the vertical refresh rate, or the vertical scan frequency. Now you are ready to test your new video mode. You probably will want to fine tune your new video mode. I take the new mode, create 2 to 10 more video modes which are slightly different (I do not calculate new video modes, I take the video mode I already have and increase or decrease one of the numbers by a small amount), run X windows, cycle through all video modes, pick the one I like best, create 2 to 10 more video modes slightly different from my new pick, cycle through all video modes, pick the one I like the best, and so on until I decide it is optimized. I cannot change t4 because that would change the horizontal synchronization frequency. I first try increasing t1 because increasing t1 gives me more pixels and a bigger image. If I want to move the image to the left, I increase t2 and/or t3. If I want to move the image to the right, I decrease t2 and/or t3. After I think t1, t2, t3, and t4 are optimized, I check l1. If I changed t1, I recalculate l1 based on the new t1. Then I try reducing l4 because reducing l4 results in a faster (better) vertical synchronization frequency, and may result in a larger image. I increase or decrease l2 and or l3 to move the image up or down. If the image is too tall (or too short), then in theory you should increase (or decrease) l4; however I find that increasing l4 has little effect except to reduce the vertical synchronization frequency; I have to decrease (or increase) l1 to make the image shorter (or taller). Sometimes I verify video modes by running a program like xclock with a square geometry, and I measure the height and width of the window to make sure it is really square. I found that changing the synchronization pulses has a small effect, but not as much effect as I expected. I expected that increasing l4 would make the image shorter, but it did not happen. (xvidtune has the same expectation; when you click on shorter, xvidtune increases l4.) Apparently, my display (BSR (made by Hyosung) 14 inch 1024x768) is able to partially compensate for bad video modes; I guess it detects when pixels are being sent and when pixels are not being sent, and resynchronizes and resizes the image based on that. The good news is that I can be sloppy about creating video modes, and the display may still work. The bad news is that when my display does not display a video mode correctly, there is not much I can do about it; if I try to adjust the video mode to compensate for the display's errors, the display compensates for the compensation, and the errors remain. I do not know if most displays are like this, or if my display is unusual. Note that the Xfree86 video timings howto describes a more complicated method of setting the synchronization pulses. It says to set the time of the pulse, then calculate the number of clock ticks from the time, etc. My method is simpler, and the video modes I calculated my way worked better than the video modes I calculated the complicated way. If your display is a multisync displays instead of a fixed frequency display, then you could create video modes in the same way. However, you would probably prefer to start with the clock speed and number of visible pixels per horizontal line, instead of starting with the clock speed and horizontal synchronization frequency. Therefore, to find out what video modes you have available, make a list of all possible display controller clock speeds, make a list of all possible horizontal synchronization frequencies (or possible numbers of visible pixels per horizontal line), and calculate the mode for each possible combination. This will give you many theoretically possible video modes. However, most of the theoretically possible video modes are not usuable. Some will involve a horizontal or vertical synchronization frequency which is too high or too low for you display. Some may use a bandwidth or resolution which is too high for your display. Some may flicker or be blurry. And some will be fine but you will never use them because you will use other modes instead. You can only use one video mode at a time; most people pick one that they like and use that all the time and never use any other video modes; however you may have to try many different video modes in order to find one that you like. To find out all possible display controller clock speeds, probe your display controller with run the command 'X -probeonly 2> output;less output'. This is assuming that 'X' is a link to the server you have chosen, and you already have an XF86Config file. Look for some lines like the following: (--) SVGA: clocks: 25.23 28.32 41.16 36.08 31.50 39.99 45.08 49.87 (--) SVGA: clocks: 64.98 72.16 75.00 80.01 85.23 So I have 13 possible clock speeds. The numbers are given in megahertz: '25.23' means 25,230,000 ticks per second. The X server first attempts to indentify your display controller. If the X server identifies your display controller, and if the X server knows what clock speeds your display controller can use, then the X server lists the speeds it knows, which are programmed into the X server. If the X server does not know the clock speeds of you display controller, then the X server measures the clock speeds. You will get a more accurate measurement of your clock speeds if you kill as many processes as possible before probing, then probe several times and average the results. Unfortunately there is not an easy way to tell if the X server is listing clock speeds it already knows or if the X server is measuring your clock speeds. Slow clock speeds are for low resolutions, and high clock speeds are for high resolutions. I probably will not be using very high resolutions. Therefore I probably will never use video modes based on the highest clock speeds. Therefore I could skip the highest clock speeds. The manual for my display says that the bandwidth is 40 megahertz. That means that the display might get blurry if I use a clock speed faster than 40 megahertz. Therefore I could skip all clock speeds of more than 40. However it is usually possible to use a clock speed a little faster than the bandwidth, and it does not hurt to try; if the resulting video modes are too blurry, I will delete them. So I will skip the 4 fastest speeds, and try the others. If you have a display with fixed horizontal synchronization frequencies, then it is probably a waste of time to generate video timings from scratch. Microsoft Windows usually uses video modes of 604x480, 800x600, and 1024x768. xf86config suggest the following video modes, which are very similar to the standard Microsoft Windows modes: # 640x480 @ 60 Hz, 31.5 kHz hsync Modeline "640x480" 25.175 640 664 760 800 480 491 493 525 # 800x600 @ 56 Hz, 35.15 kHz hsync ModeLine "800x600" 36 800 824 896 1024 600 601 603 625 Displays with fixed horizontal synchronization frequencies are probably optimized for Microsoft Windows video modes; if you try all possible video modes and select the video modes which work best, you will probably end up with something like the list above. So it is less work to start with the list above, and check to see if slightly different modes might be a little better, or just use that list as is. In my case, I found that I could increase the number of visible horizontal pixels without changing the total number of horizontal pixels; this gave me a little better resolution with a slightly larger image (the dark edges of the display were smaller); and I found that I could increase the number of visible vertical pixels to match the increase in visible horizontal pixels, and I could reduce the total number of vertical pixels, giving me a faster vertical refresh frequency. On the other hand, I found that if I tried to use a video mode significantly different from the list above, the display distorted the image. My display is so optimized for Microsoft Windows modes that I cannot use any other video modes. If you do not have a lot of video memory, you might want to choose video modes which maximize use of video memory. For example, Microsoft Windows usually uses 640 x 480, 800 x 600, or 1024 x 768 visible pixels. With 8 bits per pixel (256 colors), these modes use 307,200; 480,000; and 786,432 bytes of memory. With 16 bits per pixel (65,536 colors), they use twice as much memory. Display controllers usually have .5, 1, 2, 4, 8, 16, or 32 megabytes of video memory. How about some video modes which use just under .5, 1, or 2 megabytes? Try these modes: 832 x 624, 1,176 x 882, 1,672 x 1,254 visible pixels. With 8 bits per pixel, these modes use 519,168; 1,037,232; 2,096,688 bytes of video memory. With 16 bits per pixel they use twice as much memory; with 4 bits per pixel they use half as much. If you want a height to width ratio of anything other than .75; if you have a different amount of memory; or if you want numbers for 12, 20, or 24 bits per pixel; then: Start with the number of bytes of memory, divide by the number of bytes per pixel (number of bits per pixel divided by 8), divide by the height to width ratio (.75), take the square root, round down to the next multiple of 8, and the result is your number of visible pixels per horizontal line. If you have fixed horizontal synchronization frequencies, instead of putting the exact frequencies in XF86Config, put a range plus or minus 1 to 3 percent. For example, if your display has a frequency of 31.5 kilohertz, put 31-32. If you put the exact frequency, the X server will refuse to use any video mode which does not exactly match the frequency. I think that if the frequency of the video mode is within 1 percent of the frequency of your display, that is close enough.