There are some fundamental things you need to know before hacking an Xconfig entry. These are:
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.
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
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:
wga
Clocks 25 28 40 3 50 77 36 45 0 0 79 31 94 65 75 71
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% 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):
640x480 25
800x600 36
1024x768 65
1024x768 interlaced 45
1280x1024 110
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:
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
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.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter