Date: Tue, 03 Jan 1995 23:11:25 -0700 From: Steve Passe <fbsd@clem.systemsix.com> To: dusio <dusio@ws062.bytex.network.com> Cc: questions@freebsd.org Subject: Re: Can't get 1024x768 in Xfree Message-ID: <199501040611.XAA08269@clem.systemsix.com>
next in thread | raw e-mail | index | archive | help
>> 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! xf86-3.1 uses HorizSync and VertRefresh to protect the monitor. If the modeline math works out to be outside of the ranges declared in these two fields the server will drop them from usage during initialization. Notice of this goes to stdout (stderr?) on the tty that you invoke startx from. It happens pretty early in the sequence and usually will be scrolled off the screen by the time you leave X. To capture it do: % startx 1>/tmp/Xlog 2>&1 now from within an xterm you can: % more /tmp/Xlog to see what happened on the way up. Or try: % tail -f /tmp/Xlog to keep a running view of what happens often times when in the fine-tune stage you use numbers that push you just beyond the limit. eg, I was tuning numbers for a monitor with an Hsync range of 30-65 and came up with numbers that calculated to an actual value of 65.4 by the X server, which then promptly threw that line out. It took awhile to notice, once I did I bumped the high end of both ranges up a little to prevent this while fiddling with the numbers. Once I arrived at something I liked I reset the ranges. (use this method at your own risk!). >> I didn't include the Bandwidth specification because it doesn't >> seem to be used by drivers. as above, I believe the server would toss the line if the stated clock rate was above the Bandwidth spec, but I have never actually tried this to prove it. In anycase, the clocks listed in the sample XF86Config file are all below 100 and thus this is not an issue here. >> 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. I agree, keep things 'square'. 1280x960 also gives room for a slightly higher refresh rate. unfortunately, none of the listed clocks would give acceptable refresh rates at 1280. 1280x1024 @60Hz requires approx a 110Mhz clock. the weak link here is the ramdac speed, check it carefully when buying a new board. 4 MB of memory might get you true color, but unless the ramdac is at least in the 110-120 Mhz range you will NOT be able to use that memory for the 1280 dot modes. (unless you really like the 'strobe effects') to get above 70Hz refresh you need around 135Mhz ramdac (and clock). note again that the driver will toss a line if it attempts use of a clock higher than the ramdac's rated speed, even if the clock is truly available on the board. I should state here that all of the above claims I make about the driver doing the 'good thing' with these numbers is based on my experience with the XF86_S3 driver, I do not know for a fact that this applies to all the XF86_xxx drivers, have not looked at the source to see at what level this is accomplished.... >> 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 check out the file modeDB.txt, "MONITOR SECTION". at the head there is a list of VESA timings which will work as starting points for most any newer monitor. find the one with the highest clock rate provided by your board @ the desired resolution and start there. with the listed clocks I would pick "VESA 1024x768@70Hz" the ModeLine is: "1024x768" 75 1024 1048 1184 1328 768 771 777 806 (but change clock from 75 to 73.9) btw, these clocks look very fishy to me also! Steve Passe smp@csn.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501040611.XAA08269>