* Modeline Calculator

The Calculator

For those who are in a hurry and who know what a "modeline" is, here's the calculator. The documentation is below.

Required inputs:

Horizontal resolution pixels

Vertical resolution pixels
Refresh rate Hz

Options:

FB output mode (default is xf86 mode)

Interlaced mode

Image margin (to correct overscan)

Computation details

Results:

This calculator is available as a command-line Ruby program released under the GPL:

The Documentation

General

This project began when I realized what the existence of YouTube, Hulu and other new video sites actually signifies — nothing less than the beginning of the end of conventional broadcast television. It won't be long before the advantages of Internet video delivery will become obvious to everyone, the existing Internet infrastructure will be overhauled to accommodate more demanding data rates, and the old network broadcasting system will be torn down and hauled away.

From a larger perspective, this video-delivery routing change is a part of a more sweeping change. In the future, many of the services that deliver or require information from a house will be combined into a single optical fiber. In the time just ending, a typical house might require:

A TV cable.

A telephone line.

An Internet connection.

An alarm system to deal with fire and burglars.

Personal visits by someone to record your electric and water usage.

With less probability, visits to monitor your gas and heating oil usage.

These services can be combined and made more efficient through use of modern network technologies, while at the same time improving the quality of service and reducing labor and environmental costs (like someone driving around reading electric and water meters).

Minor digression: For this future to come to pass, every imaginable gadget — every electric meter, burglar alarm and toaster — will need to be connected to the Internet, which means all of them will need distinct addresses. A new Internet addressing scheme (IPV6) has been designed, with enough address space to allow every imaginable gadget to have its own address. But because the new addressing scheme has yet to be adopted, we face the prospect of running out of old-style (IPV4) addresses within a decade.

Specific

That's the big, long-term picture. On a smaller scale, in this article I will describe my recent project to connect a laptop to my big Pioneer plasma panel, so I can watch online video content on a reasonably sized screen. I have to tell you that a number of current video streaming sites already have content that makes a big display worthwhile. None of them offer true HDTV (primarily for reasons of limited bandwidth), but as the years go by image quality is gradually improving, already enough to justify a big display.

But there is a problem with a lot of current HDTV displays — many connect to a computer only reluctantly, and with primitive protocols. My plasma panel offers two ways to connect — I can create an HDTV signal and send it along a special three-conductor video cable, or I can exploit the fact that the panel doubles as a computer monitor.

As to the laptop (a Dell XPS M1710), it knows how to generate a normal HDTV signal (Dell provides a special connector for this purpose), or I can connect the plasma panel as an external monitor. Each of these choices requires some setting up — it's not a matter of connecting up and expecting the system to sort it out. That may become possible in the future, but it's certainly not true now.

As time passes, computer operating systems have become more sophisticated about how they communicate with video displays, and the video displays have improved in turn. There is a comunications protocol called EDID (Extended Display Identification Data) that allows a video display to describe itself to a computer, and many modern displays support this protocol.

But EDID is by no means universal — there are many displays that can't describe themselves to a computer, and in these cases the computer needs to be told about the display in an explicit way. That "explicit way" is called a "modeline," a terse, rather cryptic line of information that describes one mode of a video display (multiple modes require multiple modelines). It's important to say that a modeline stands in for the display's EDID information, and is usually not as good — some guesswork is almost always required. It is also important to say that some seemingly reasonable modelines can damage monitors, so this method of hand-crafting monitor descriptions includes a certain amount of risk.

On Linux systems, modelines have become less important, because most modern displays support EDID and current software knows how to gather this information. But because not all displays support EDID, including some new equipment, modeline computers like this page will remain useful. Oh, by the way, did I mention that my Pioneer plasma panel doesn't support EDID?

Technical

I have any number of computer displays floating around, and most of them support EDID. But it seems that all my multipurpose displays (basically TV sets with a computer display connector included) don't know about EDID, including the aforementioned plasma panel.

In the optimal case, when a modern display is connected to a computer, a conversation like this takes place:

  Yo, monitor! Give it up!

  Here's what I can do for you (very long list of allowed modes).

  Cool ... (process, process) ... here's your picture ... (video data).

In the case of a typical TV with a computer display connector as an added feature, it may be something like this instead:

  Yo, monitor! Give it up!

  (long silence).

  Uhh ... I can deal with this ... (process, process, process) ... gag ... choke ... strangle.

My rather expensive plasma panel falls into the second category. I tried various ways to get it to accept a laptop's video output, but with no success. Then I did a bit of research and discovered the reason — the plasma panel wouldn't provide EDID information, and without either EDID data or a modeline, the laptop couldn't sort things out.

In the next phase of my project, I started writing modelines and inserting them into the X Windows configuration file. But none of them would produce a properly sized and centered picture. In order to solve this problem, I had to learn what information the modeline actually conveyed, and hand-tune the values.

Modelines in depth

Now for a closer look at modelines and what they contain. First, here is a typical modeline with the image size I needed for my panel (image size 1280x768, 60 Hz refresh rate):

Modeline "1280x768_60.00" 80.14 1280 1344 1480 1680 768 769 772 795 -HSync +Vsync

Here's a modeline with descriptive labels instead of numbers:

Modeline "String description" Dot-Clock HDisp HSyncStart HSyncEnd HTotal VDisp VSyncStart VSyncEnd VTotal [options]

Here is a diagram that shows how some of the labels correspond to a horizontal line of video:

Figure 1: Horizontal video line

The vertical values (VDisp, VSyncStart, VSyncEnd, VTotal) are laid out in the same way but on a different time scale, one where the quanta are not pixels but horizontal lines.

Here's some more detail. The "Dot-Clock", with units of megahertz, is the rate at which pixels are drawn. In this example with a dot-clock of 80.14*10⁶ Hz, a pixel is drawn every 1/(80.14*10⁶ Hz) or roughly every 12 nanoseconds. Computing the dot-clock is actually one of the simpler parts of the modeline computation — it's equal to the refresh rate * HTotal * VTotal (the '*' asterisk is used in computer programming to signify multiplication):

Refresh rate * HTotal * VTotal = Dot-Clock
60 * 1680 * 795 = 80,136,000 or 80.14 * 10⁶ Hz

I want to warn my readers that only a handful of modeline computations are as simple as this example. In the full computation, there are a number of areas where whim, taste, and certain hardware limitations play a part, which explains why no two modeline computers seem able to produce the same results.

Adjustments

Please examine Figure 1 on this page, the graphic that shows one horizontal line of video. Much of modern video display technology is borrowed from television, and television's technical standards have their roots in a much simpler time. Even though most computer data transfers depend on very robust network-based protocols, the data transfers between a computer and a video display have a distinctly primitive quality. Each horizontal video line consists of:

A visible area with a span equal to HDisp pixels (blue color in Figure 1).

A blanking interval with a span equal to HTotal - HDisp (gray color).

A sync pulse within the blanking interval with a span equal to HSyncEnd - HSyncStart (red color).

In many cases the default modeline computer on this page will solve problems created by a display that does't know about EDID. But if the resulting display is not the right size or is not in the right position, it may be possible to correct this problem by hand-tuning the modeline values. The reader is warned that hand-tuning modeline values is a risky business and can damage your monitor.

Here is a list of symptoms and remedies:

Symptom Remedy

Image too far to the right/left Add/subtract multiples of 8 from both HSyncEnd and HSyncStart. This assures that the sync pulse has the same width (which it must have), and is moved within the blanking interval. Important note: While making this change, avoid allowing either HSyncEnd or HSyncStart to exceed the dimensions of the blanking interval, that is, both these values should meet this condition: HDisp <= v <= HTotal.

Image too wide/narrow Add/subtract a small value from HTotal, repeat as required. Be careful with this adjustment — it changes the duration of the blanking interval.

Image too low/high Add/subtract small increments from both VSyncEnd and VSyncStart in the same way as above, with the same constraints: VDisp <= v <= VTotal.

Image too tall/short Add/subtract a small value to VTotal, repeat as required, and be careful as explained above.

Note that horizontal modeline values must all be expressed and changed in multiples of 8. This is important to remember when smaller increments have no effect or cause strange things to happen.

Symptom	Remedy
Image too far to the right/left	Add/subtract multiples of 8 from both HSyncEnd and HSyncStart. This assures that the sync pulse has the same width (which it must have), and is moved within the blanking interval. Important note: While making this change, avoid allowing either HSyncEnd or HSyncStart to exceed the dimensions of the blanking interval, that is, both these values should meet this condition: HDisp <= v <= HTotal.
Image too wide/narrow	Add/subtract a small value from HTotal, repeat as required. Be careful with this adjustment — it changes the duration of the blanking interval.
Image too low/high	Add/subtract small increments from both VSyncEnd and VSyncStart in the same way as above, with the same constraints: VDisp <= v <= VTotal.
Image too tall/short	Add/subtract a small value to VTotal, repeat as required, and be careful as explained above.

Picky Details

Over time, with newer displays and more sophisticated video software, the need for explicit modelines will go away. But for a while yet to come, we're going to encounter operating systems and/or displays that won't be able to sort things out on their own. So ... bookmark this page.

I run Fedora, and my X Windows configuration file is located at /etc/X11/xorg.conf. If you are running a recent version of Fedora, the following will probably be in reasonable agreement with the content of your configuration file.

In order to work as it should, the xorg.conf file has an internal hierarchical order (and I am leaving out a bunch of sections not relevant to the present issue). The following sections must be present:
A "ServerLayout" block that refers to a "Screen" block:
Section "ServerLayout"
    Identifier     "Default Layout"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "SynapticsTouchpad" "CorePointer"
EndSection
A "Screen" block that refers to both a device (video card) block and a monitor block:
Section "Screen"
    Identifier     "Screen0"
    Device         "Videocard0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection
A device block for the videocard driver:
Section "Device"
    Identifier     "Videocard0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 8600 GTS"
    Option         "DPMS"
EndSection
And a monitor block:
Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    Option         "DPMS"
EndSection
It turns out this gory level of detail is really necessary, because one or more modelines can placed in the monitor block, like this:
Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       30.0 - 83.0
    VertRefresh     56.0 - 76.0
    # 1280x768 @ 60.00 Hz (GTF) hsync: 47.70 kHz; pclk: 80.14 MHz
    Modeline "1280x768_60.00" 80.14 1280 1344 1480 1680 768 769 772 795 -HSync +Vsync
    Option         "DPMS"
EndSection
The comment line my calculator creates isn't needed for the modeline to work, it's just a convenient way to remember the details of a particular modeline.

Conclusion

Until recently I only thought about transferring video from cable or satellite to my computer system, using technologies like Slingbox. Things are now changing dramatically, and it's about time to reverse the flow of information (from computer to TV).

I ask my readers to think about this change. A huge physical and legal infrastructure supports broadcast radio and television, with monster transmitters and antennas atop many otherwise nice-looking mountains. A huge amount of power is expended to transmit televsison signals through the ether, and if there isn't a clear line of sight between your house and the transmitter, the result can be dismal. And the impending conversion to digital television is going to make that problem worse — a location with marginal analog pictures may not receive digital TV at all (something I know from personal experience).

From a different perspective, many Internet service providers are reluctant to install the capacity required for streaming video, and some basic scientific work will be required to improve the entire system's bandwidth — but over time, bandwidth will increase while dropping in cost (continuing a long-term historical trend).

Think about the end of broadcast television. It will happen, indeed it has started, and it will mean more media voices, each with a smaller audience. There won't necessarily be a role for a single media spokesperson talking to millions of people at a particular time of day. We may be witnessing the end of the media superstar.