Setting Up X11

by Greg Lehey

One of the best things about Linux is XFree86, the free windowing system built on top of X11R6. The current version, 3.1.1, runs on just about any hardware, so that there is very little reason why you shouldn't be running it.

Are you running XFree86? That's a different question. If you answer no, then this article may be for you.

Another great thing about Linux is that it runs on PCs, which have arguably the highest performance/price ratio of any computer family. (Yes, I know, people argue this point constantly.)

Unfortunately, there are hardly two PCs with the same hardware configuration; in the course of the PC's evolution, hundreds of different display boards have appeared, each with their own peculiar quirks. How come they can sell? Most people use DOS or a system derived from DOS, and the boards have the necessary driver software for DOS on the board. If you're running a real operating system, you don't want to use these drivers: they run in 16 bit mode, and they're slow. That's why XFree86 supplies its own drivers and incorporates them in the X server.

XFree86 drivers are a “good news, bad news” situation. First the bad news: setup can be more difficult. With Microsoft Windows, you install the board and the software that comes with it, and it works (well, you get a recognizable picture on the screen). With XFree86, things might not be as easy.

The good news is that the drivers are much faster and much more flexible. In particular, you can configure XFree86 to your exact combination of display board and monitor, if you know how, even though you need to tune it manually.

This may sound simple, or it may sound complex—and it is. Some people set up X in a few minutes, but others run into problems which make grown-ups cry. In this article, we'll look at:

  • How display boards and monitors work.

  • How to set up XFree86 to work with your hardware.

  • How to tune your hardware for maximum display performance.

  • How to fry your monitor.

I mean the last point seriously. Conventional wisdom says that you can't damage hardware with a programming mistake, but in this case, you can, and people do from time to time. When you've read the section on how monitors work, you'll understand, but please don't start tuning until you understand the dangers involved.

How TVs and Monitors Work

You don't have to be a computer expert to see the similarity between monitors and TVs; current monitor technology is derived from TV technology, and many display boards have modes which can use TVs instead of monitors. Those of us who were on the microcomputer scene 15 to 20 years ago will remember the joy of getting a computer display on a portable TV, a “glass tty” running at 300 or 1200 bps.

TVs and monitors display the picture by scanning lines across the screen. As in a book, the first line starts at the top left of the screen and goes to the top right. Each successive line starts slightly below the previous line. This continues until the screen is full. The lines don't have to be full; the picture is formed by altering the intensity of the electron beam as it scans the lines.

To perform this scan, the TV has two deflection units: one scans from left to right, and the other scans (much more slowly) from top to bottom. Not unexpectedly, these units are called the horizontal and vertical deflection units. You may also encounter the terms line and frame deflection.

The electron beam can move at only a finite speed. When the electron beam reaches the right hand side of the screen, it needs to be deflected back again. This part of the scan is called the horizontal retrace, and it is not used for displaying picture data. The actual time that the hardware requires for the retrace varies, but it is in the order of 5% to 10% of the total line scan time. Similarly, when the vertical deflection reaches the bottom of the screen, it performs a vertical retrace, which is also not used for display.

It's not enough to just deflect, of course; somehow you need to ensure that the scanning is synchronized with the incoming signal, so that the scan is at the top of the screen when the picture information for the top of the screen arrives. You've all seen what happens when this doesn't happen; the picture runs up and down the screen (incorrect vertical synchronization) or tears away from the left of the screen (incorrect horizontal synchronization). Synchronization is achieved by including synchronization pulses in the horizontal and vertical retrace periods. To ensure that they are recognized as synchronization pulses, they have different voltage levels from the picture data.

As if that wasn't enough, the video amplifier, the part of the TV which alters the intensity of the spot as it travels across the screen, needs time to ensure that the retrace is invisible, so there are brief pauses between the end of the line and the start of the sync pulse, and again between the end of the sync pulse and the beginning of the data. This process is called blanking, and the delays are called the front porch (before the sync pulse) and the back porch (after the sync pulse).

In a nutshell, that is how horizontal deflection works. Vertical deflection works in almost the same way, just slower, with one minor exception. This basic display mechanism was developed for TVs in the 1930s, when the term “high-tech” hadn't even been invented, and even today we're stuck with the low data rates that they decided upon in those days. Depending on the country, TVs display only 25 or 30 frames (pages of display) per second. This causes an unpleasant flicker in the display. This flicker is avoided with a trick called interlacing. Instead of displaying the frame in one vertical scan, the odd and even lines are displayed in two alternating half frames, which increases the apparent frame frequency to 50 or 60 Hz.

How Monitors Differ from TVs

So how do we apply this to computer displays? Let's look at the US standard NTSC system—the international PAL and SECAM systems are almost identical except for the number of lines and a minor difference in the vertical frequency. NTSC specifies 525 lines, but that includes the vertical blanking time, and in fact only about 480 lines are visible. The aspect ratio of a normal TV is 4:3, in other words the screen is one-third wider than it is high, so if we want square pixels, (one with the same height and width, which makes graphics software much simpler) we need one-third more pixels per line. This means that we can display 640 pixels per line on 480 lines. (Do these numbers look familiar? Now you know why.)

This resolution is normally abbreviated to “640*480”. PAL and SECAM have lower vertical frequencies, which allow a nominal 625 lines, of which about 580 are displayed. Either way, these values have two huge disadvantages: first, they are interlaced displays, and second, the resolution is the minimum acceptable for modern graphics displays. Older PC display hardware, such as the CGA and some EGA modes, was capable of generating these signal frequencies, but VGAs can no longer do it. This is a pity, in some ways; I'd like to have an X display on my TV in the lounge room, but my last EGA adaptor died a couple of years ago.

The first problem with these standards is interlace. It works reasonably for TVs, but it's a pain for computer displays—there's still more flicker than with a real 50 Hz or 60 Hz display. VGAs can still be run in interlace mode, but you shouldn't even think about doing so unless you're into masochism. The second problem is the resolution; nowadays, 1024*768 is a normal enough resolution, but I'm writing this on a display with 1280*1024, and many modern boards display 1600*1200. On the other hand, even 60 Hz refresh rate is barely adequate. Read any marketing literature and you'll discover that 72 Hz is the point at which flicker suddenly disappears. To get high-resolution, high-refresh-rate displays, you need some very high internal frequencies—we'll see how high further down.

How to Fry Your Monitor

Now we know that a monitor is just a glorified TV. TVs were designed to use the same circuitry for the horizontal deflection as well as generation of the high voltage required for the CRT. This simplified the hardware design at the expense of versatility loss. The flyback transformer which generates the high voltage is part of a resonant circuit which can only operate at one frequency. Run a flyback transformer off its intended frequency and it will run much less efficiently and use more power. This additional power will be dissipated in the flyback transformer and horizontal output transistor as heat. The result can be the failure of the flyback transformer, the transistor, or both.

You don't have to roll your own X configuration to burn out the monitor. Ten years ago, the standard display boards were CGAs (Color Graphics Adapter) and HDAs (Hercules Display Adapter) and they had different horizontal deflection frequencies and thus required different monitors. If you connected an HDA (18.43 kHz horizontal deflection frequency) to a CGA monitor (15.75 kHz, the NTSC horizontal deflection frequency), you could expect smoke signals within a few minutes.

In modern PC monitors the horizontal deflection and high voltage generation circuits have been separated. Called multi-sync monitors, they are capable of running at a range of deflection frequencies. Running at any of the frequencies in the specified range will work, but it is still possible to damage the monitor by running it out of the specified range. Note that just beacuse a monitor displays the image correctly doesn't mean that it is running in spec. I have a rather elderly Eizo 9500 (called Nanao in the US) which has three frequencies: (exactly) 31.5 kHz, 48 to 50 kHz, or 64 to 78 kHz. In fact, it will display at any frequency between 48 and 78 kHz, but if it were run at 57 kHz for any length of time, I would be in for a hefty repair bill. The moral of the story: Don't ever run your monitor out of spec. If your display is screwed up, there's a good chance that the frequencies are out. Turn off the monitor.

Monitors aren't the only thing that you can burn out, of course. If you try hard, you can also burn out chips on some display boards by running them at frequencies which are out of spec. In practice, though, this doesn't happen nearly as often.

Another difference between TVs and monitors is the kind of signal they take. A real TV includes a receiver, of course, so you have an antenna connection, but modern TVs also have connections for inputs from VCRs, which are usually an audio signal and a video signal. The video signal consists of five important parts: the red signal, the green signal, the blue signal, and the horizontal and vertical sync pulses. This kind of signal is called composite video. By contrast, most modern monitors separate these signals onto separate signal lines, and older boards, such as the EGA, even use several lines per colour. Unfortunately, there is no complete agreement about how these signals should work; the polarity of the sync pulses varies from one board to the next, and some boards cheat and supply the sync pulses on the green signal line. This is mainly of historical interest, but occasionally you'll come across a real bargain 20" monitor which only has 3 signal connections, and you may not be able to get it to work—this could be one of the reasons.

The CRT Controller

The display controller, usually called a CRT (Cathode Ray Tube) controller, is the part of the display board which creates the signals we've just been talking about. Early display controllers were designed to produce signals that were compatible with TVs. They had to produce a signal with sync pulses, front and back porches, and picture data in between. Modern display controllers can do a lot more, but the principles remain the same.

The first part of the display controller creates the framework we're looking for: the horizontal and vertical sync pulses, blanking, and picture information, which is represented as a series of points or dots. To count, we need a pulse source, which also determines the duration of individual dots, so it is normally called a dot clock. For reasons lost in history, CRT controllers start counting at the top left of the display, and not at the vertical sync pulse, which is the real beginning of the display. To define a line to the horizontal deflection, we need to set four CRTC registers to tell it:

  • The Horizontal Display End (HDE) register specifies how many dots we want on each line. After the CRTC has counted this many pixels, it stops outputting picture data to the display.

  • The Start Horizontal Retrace (SHR) register specifies how many dot clock pulses occur before the sync pulse starts. The difference between the contents of this register and the contents of the HDE register defines the length of the front porch.

  • The End Horizontal Retrace (EHR) register defines the end of the sync pulse. The width of the sync pulse is the difference between the contents of this register and the SHR register.

  • The Horizontal Total (HT) register defines the total number of dot clocks per line. The width of the back porch is the difference between the contents of this register and the EHR register.

In addition, the Start Horizontal Blanking (SHB) and End Horizontal Blanking (EHB) registers define when the video signals are turned off and on. The server sets these registers automatically, so we don't need to look at them in more detail.

The control of the vertical deflection is similar. In this case, the registers are Vertical Display End (VDE), Start Vertical Retrace (SVR), End Vertical Retrace (EVR), Vertical Total (VT), Start Vertical Blanking (SVB), and End Vertical Blanking (EVB). The values in these registers are counted in lines.

VGA hardware evolved out of older 8 bit character-based display hardware, which counted lines in characters, not dot clocks. As a result, all of these registers are 8 bits wide. This was adequate for character displays, but it's a problem when counting dots. The maximum value you can set in any of these registers is 255. The designers of the VGA resorted to a number of nasty kludges to get around this problem. The horizontal registers count in groups of 8 dot clocks, so they can represent up to 2048 dot clocks. The vertical registers overflow into an overflow register. Even so, the standard VGA can't count beyond 1024 lines. Super VGAs vary in how they handle this problem, but typically they add additional overflow bits. To give you an idea of how clean the VGA design is, on a standard VGA, the real Vertical Total (total number of lines on the display) is defined as the value of the VT register +256 if bit 0 of the overflow register is set, or +512 if bit 5 of the overflow register is set.

The XF86Config Mode Line

One of the steps in setting up XFree86 is to define these register values. Fortunately, you don't have to worry about which bits to set in the overflow register. The mode lines count in dots, and it's up to the server to convert the dot count into something that the display board can understand. A typical Mode line looks like:

"640x480a" 28 640 680 728 776 480 480 482 494

These ten values are required. In addition, you may specify modifiers at the end of the line. The values are:

  • A label for the resolution line. This must be enclosed in quotation marks, and is used to refer to the line from other parts of the XF86Config file. It is the only optional field—further down we'll look at what happens if it isn't present. Traditionally, the label represents the resolution of the display mode, but it doesn't have to. In this example, the resolution really is 640*480, but the a at the end of the label is a clue that it's an alternative value.

  • The clock frequency. This may be a label, like the mode line label, but sometimes it really does have to match the clock frequency in MHz.

  • The Horizontal Display End, which goes into the HDE register. This value and all that follow are specified in dots. The server mangles them as the display board requires and puts them in the corresponding CRTC register.

  • The Start Horizontal Retrace (SHR) value.

  • The End Horizontal Retrace (EHR) value.

  • The Horizontal Total (HT) value.

  • The Vertical Display End (VDE) value. This value and the three following are specified in lines.

  • The Start Vertical Retrace (SVR) value.

  • The End Vertical Retrace (EVR) value.

  • The Vertical Total (VT) value.

As I noted, not every mode line needs a label. It's possible to have a number of mode lines for the same resolution, each with a different dot clock frequency. In this case, only the first line of a group needs the label.

This is pretty dry stuff. To make it easier to understand, let's look at how we would set a typical VGA display with 640*480 pixels. Sure, you can find values for this setup in any release of XFree86, but that doesn't mean that they're the optimum for your system. We want a no-flicker display, which we'll take to mean a vertical frequency of at least 72 Hz, and of course we don't want interlace. Our multiscan monitor can any handle horizontal frequency between 15 and 40 kHz, so let's head for the highest and see what happens.

First, we need to create our lines. They contain 640 pixels, two porches, and a sync pulse. The only value we really know for sure is the number of pixels. How long should the porches and the sync pulses be? If you have a good monitor with good documentation, it should tell you, but most monitor manufacturers don't seem to believe in good documentation. When they do document the values, they vary significantly from monitor to monitor, and even from mode to mode. They're not as critical as they look. For example, here are some typical values from my NEC 5D handbook—Horizontal sync pulse: 1 to 4 µs, front porch 0.18 to 2.1 µs, back porch 1.25 to 3.56 µs.

As we'll see, the proof of these timing parameters is in the display. If the display looks good, the parameters are OK. I don't know of any way to damage the monitor purely by modifying these parameters, but there are other good reasons to stick to this range. As a rule of thumb, if you set each of the three values to 2 µs to start with, you won't go too far wrong. Alternatively, you could start with the NTSC standard values. The standard specifies that the horizontal sync pulse lasts for 4.2 to 5.1 iµs, the front porch must be at least 1.27 µs. NTSC doesn't define the length of the back porch—Winstead it defines the total line blanking, which lasts for 8.06 to 10.3 µs. For our purposes, we can consider the back porch to be the length of the total blanking minus the lengths of the front porch and the sync pulse. If you take values somewhere in the middle of the ranges, you get a front porch of 1.4 µs, a sync pulse of 4.5 µs, and total blanking 9 µs, which implies a back porch of 9 - 1.4 - 4.5 = 3.1 µs.

For our example, let's stick to 2 µs per value. We have a horizontal frequency of 40 kHz, or 25 µs per line. After taking off our 6 µs of total blanking time, we have only 19 µs left for the display data. In order to get 640 pixels in this time, we need one pixel every 19/640 µs, or about 30 ns. This corresponds to a frequency of 33.6 MHz. This is our desired dot clock.

The next question is: Do we have a dot clock of this frequency? Maybe. This should be in your display board documentation, but I'll take a bet that it's not. Never mind, the XFree86 server is clever enough to figure this out for itself—we'll see how the next article. At the moment, let's assume that you do have a dot clock of 33 MHz. You now need to calculate four register values to define the horizontal lines:

  • The first value is the Horizontal Display End, the number of pixels on a line. That's easy enough—it's 640.

  • You calculate SHR by adding the number of dot clocks that elapse during the front porch to the value of HDE. Recall that we decided on a front porch of 2 µs. In this time, a 33 MHz clock will count 66 cycles. So we add 66, right? Wrong. Remember that the VGA registers count in increments of 8 pixels, so we need to round the width of the front porch to a multiple of 8. In this case, we round it to 64, so we set SHR to 640 + 64 = 704.

  • The next value we need is EHR, which is SHR plus the width of the horizontal retrace, again 64 dot clocks, so we set that to 704 + 64 = 768.

  • The final horizontal value is HT. Again, we add the front porch—64 dot clocks—to EHR and get 768 + 64 = 832.

Next, we need another four values to define the vertical scan. Again, of the four values we need, we only know the number of lines. How many lines do we use for the porches and the vertical sync? As we've seen, NTSC uses about 45 lines for the three combined, but in practice modern monitors get by with many fewer. Again referring to the Multisync manual, we get a front porch of betwwen 0.014 and 1.2 µs, a sync pulse of between 0.06 and 0.113 µs, and a back porch of between 0.54 and 1.88 µs. But how many lines is that?

To figure that out, we need to know our real horizontal frequency. We were aiming at 40 kHz, but we made a couple of tradeoffs along the way. The real horizontal frequency is the dot clock divided by the horizontal total, in this case 33 MHz / 832, which gives us 39.66 kHz—not bad at all. At that frequency, a line lasts just over 25 µs, so our front porch can range between ½ and 48 lines, our sync pulse between 2 and 5 lines, and the back porch between 10 and 75 lines. Do these timings make any sense? No, they don't—they're just values which the monitor can accept.

In practice, we can go for the lowest value in each case. It's difficult to specify a value of ½, so we'll take a single line front porch. We'll take two lines of sync pulse and 10 lines of back porch. This gives us:

  • VDE is 480.

  • SVR is 481.

  • EVR is 483.

  • VT is 493.

Now we can calculate our vertical frequency, which is the horizontal frequency divided by the vertical total, or 39.66/493 kHz, which is 80.4 Hz—not bad at all. By comparison, if you use the standard entry in XF86config, you will get a horizontal frequency of 31.5 kHz and a vertical frequency of only 60 Hz.

If you know the technical details of your monitor and display board, it really is that simple. This method doesn't require much thought, and it creates results which work. This doesn't mean that they are optimal values—we'll look at that in the next article.

Greg Lehey is a partner in LEMIS-Lehey Micro-computer Systems. He resides in Germany.

Load Disqus comments

Firstwave Cloud