Date: Tue, 03 Jan 1995 19:01:32 -0800 From: Dave Tweten <tweten@gilmore.nas.nasa.gov> To: dusio <dusio@ws062.bytex.network.com> Cc: questions@freebsd.org Subject: Re: Can't get 1024x768 in Xfree Message-ID: <199501040301.TAA03490@gilmore.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
dusio writes: >I am using X, but am >unable to get a resolution higher than 640x480. My battle was to get XFree86 working with a Mach32 video board and a Nanao T560i monitor, so what follows will necessarily be general. >I have read the "Hitchhiker guide to >Xfree/X386 Video Timing" by Eric S. Raymond, and have >performed the calculations therein. This is a good place to start. It's not the finish line (as Raymond points out). After you calculate the right dot-clock frequency and two groups of four magic numbers for a mode, card, and monitor, you then have to experiment with it to make it right. The Hitchhiker's Guide makes several conservative assumptions. In my experience, the result is stable, but usually not pretty. Once you have a stable display, you need to begin experimenting to get it centered, large enough, and in proportion (so you get square pixels -- and round circles). The last few pages of the Guide tell how to do this. You shorten or lengthen the blanking interval (difference between the first and last numbers in a four-number group) to expand or shrink the display in the coresponding dimension. You also adjust your dot clock frequency to scale the display area. To get the largest display area most easily, use the lowest dot clock frequency that produces an acceptably high refresh rate. Any refresh rate above 70 Hz should produce no observable flicker. What lower refresh rate may be acceptable is a matter of taste. You shift the sync pulse (which begins with the second number and ends with the third) to center the display in the coresponding dimension. Finally, you adjust the sync pulse widths and margins you started with, pushing the limits of the Guide's recommendations, to center and size the display. Experimentation is king. If the display won't sync up, or if "snow" starts to show up on the left edge of the display area, you have made the horizontal sync pulse too short or have put it too close to the end of the scan line. If the first few lines at the top of the display area are unevenly spaced, or if they are shifted to the right as compared to lines below, or if the first line doesn't start at the left edge, then you have made the vertical sync pulse too short or have put it too close to the end of the field. Every time you make a change, be sure that your new ModeLine still fits within your monitor's horizontal and vertical sync limits. Significantly out-of- limits sync rates can damage some monitors! I've excerpted the interesting parts of your XF86Config file, below: > Clocks 19.9 22.3 24.8 25.0 28.1 31.3 > Clocks 32.2 35.7 35.9 37.0 39.8 > Clocks 39.7 44.6 49.6 49.9 56.2 62.6 > Clocks 64.4 71.4 71.8 73.9 79.6 > HorizSync 30-64 > VertRefresh 50-120 >Modeline "640x400" 25.175 640 664 760 800 400 409 411 450 >Modeline "640x480" 25.175 640 664 760 800 480 491 493 525 I didn't include the Bandwidth specification because it doesn't seem to be used by drivers. That's not too surprising. An analog monitor can't tell what the dot clock rate is. Severe bandwidth abuse will only cause the display to appear fuzzy. So long as you respect your monitor's horizontal and vertical sync rate limits, no harm results. I am a little suspicious of your Clocks lines. Where did you get them? Twenty-two different clock rates seens peculiar. Selectable clock generators seem to offer a number of rates that is a power of two (probably because the rate is selected by putting a binary code into some field of an I/O register). I don't think continuous clock synthesizers use Clocks lines. It also strikes me as odd that you would build your ModeLines assuming a clock rate of 25.175 MHz when the nearest rate listed on any of your Clocks lines is 25.0 MHz. Why go out of your way to make the X server resolve the mismatch? >The two modes listed above work. But I am unable to scale >them up to 1024X768 (or 800x600 or 1280x1024). To scale up to 800x600, at the same vertical refresh rate, you will need a dot clock rate about 1.5 times the one you need for 640x480. Why? Neglecting the "pixels" devoted to horizontal and vertical blanking and sync pulses, there are about 1.5 times as many real viewable pixels to display. Assuming that X runs your 640x480 modes with the nearest Clocks value, 25 MHz, something like your 39.8 MHz clock should work at 800x600. To scale up to 1024x768 you will need a clock rate about 2.5 times the one you need for 640x480. Something near 64.4 MHz should work. You may not even want to use 1280x1024. Monitors are generally built with a 75% aspect ratio -- the viewing area is 3/4 as high as it is wide. If you want a full screen and square pixels, you want the vertical pixel count to be 75% of the horizontal count. That suggests 1280x960 instead of 1280x1024. To scale up to 1280x960 you will need a clock rate about 4 times the one you need for 640x480. That would be 100 MHz. Your Clocks lines indicate that your graphics board won't go that high. If you really want to do this you will have to use interlace. >Could it be that I need more than 32 ticks of guard time? I don't remember whether the Guide's definition of "guard time" is the portion of the horizontal blanking interval before or after the horizontal sync pulse. At 25 MHz, 32 ticks is 1.28 microseconds, which should be enough for either. >Could it be that 3.8us is too little time to stabilize the >beam? Unlikely. >Could it be that 150us is too little time for a vertical >refresh? Also unlikely. Failure of your monitor to sync up could be caused by any of these, but my first candidate for cause is your Clocks lines. I'd start by making very sure that they feature all the right values and in the right order. Order is important because drivers use a clock rate's position in the list to determine the code to write into the rate-selection port to get that clock rate. >Could it be that I did the math wrong? Possible. That's why I wrote an Excel spreadsheet from the information in the Guide, to calculate magic number sets for all my video board's clock frequencies at once. By the time I settled upon ModeLines for 1280x960, 1024x768, 800x600, and 640x480 for 8-bit pixels and for 16-bit Truecolor, I could calculate a new Modeline with a calculator in under a minute. That only happened after a lot of experimenting. The spreadsheet was invaluable to find starting points, and to help me understand the calculations. Writing your own spreadsheet is strongly recommended.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501040301.TAA03490>