| X Modeline |
| Resolution | 0 | |
| H Frequency | 0 | |
| V Frequency | Hz | |
| Pixel Clock | MHz | |
| H Resolution | 0 | |
| H Front Porch | 0 | |
| H Sync Pulse | 0 | |
| H Back Porch | 0 | |
| H Blank | 0 | 0 |
| H Total | 0 | 0 |
| V Resolution | 0 | |
| V Front Porch | 0 | |
| V Sync Pulse | 0 | |
| V Back Porch | 0 | |
| V Blank | 0 | 0 |
| V Total | 0 | 0 |
| H Sync Polarity | ||
| V Sync Polarity | ||
| Scan | ||
| H Position | ||
| V Position | ||
Editor settings |
||
| H Granularity | ||
| Preview Scale |
This is a tool for manually creating custom non-standard video timings. Use at your own risk, this tool does not validate the timings in any way! Custom signals can and have destroyed monitors! Particularly 80s and early 90s CRTs are at a high risk of becoming smoke machines.
The tool may have bugs and information on this page may be inaccurate.
The modeline is used with X Windowing System, and is the closest thing to a standard format for VGA signals. You'll find many calculators using this format, thus an automatic one is not implemented here. CSync and Doublescan flags are currently unsupported.
VGA timings are also used by digital interfaces such as DVI, HDMI and even Displayport in some capacity. This editor can be useful with digital displays for overclocking or manual creation of QFT modes, as examples.
GTF is a widely used standard from 1999. It was designed with older displays in mind, and is a good bet for most multisync CRTs.
CVT is a newer standard that superceded GTF in 2002.
CVT Reduced Blanking is for use with digital displays that do not need large porches to wait for a beam to travel around.
DMT is a set of predefined resolutions and timings. Many of these do not conform to either GTF or CVT.
All displays, including LCDs, have a range of horizontal and vertical frequencies they can operate within. Refer to your displays manual for supported ranges.
Horizontal frequency is how many horizontal lines a second your display
is drawing. It can be simply calculated by V Total * Refresh Rate.
With multisync CRT monitors you can choose how these scanlines are used:
By reducing vertical resolution, higher refresh rates are possible.
Some multisync LCD and CRT monitors seem to allow you to overclock their vertical refresh rate without issue, as long as other values (horizontal frequency, pixel clock) are within range. This is still not entierly risk-free, someone blew their Sony E200 monitor by overclocking it to 180hz, but this did also involve removing restrictions with WinDAS.
Most systems do not support arbitrary precision clocks. Expect some quantization error, your carefully set refresh rate may not be replicated accurately. A common precision is 0.5 MHz.
Pixel clock is simply the total amount of pixels a second you're trying to transmit, including the invisible blanking portions.
For analog video, pixel clock is an entierly source-side concept, most if not all CRTs are completely indifferent to this value. However, analog circuitry has a limit on how fast it can respond, commonly referred as slew rate. Quality loss is inevitable at high enough pixel clocks.
Your DAC however will have a hard pixel clock limit. The last GPU RAMDACs were usually 400MHz. Many basic HDMI-to-VGA adapters go only up to 150-200MHz, while some Displayport-to-VGA adapters can operate even at 600MHz, though a maximum of 270MHz is more common.
For Windows, Pixel Clock Patchers exist for both AMD and NVIDIA. These allow you to exceed the common 400MHz limit. Use at your own risk.
Be aware many HDMI-VGA adapters tend to not only have poor frequencies but also introduce black crush and other gamma oddities. DisplayPort-VGA adpaters seem to more often be well-behaved.
I personally use a Delock 62967 for my CRTs. The picture quality is indistinguishable from a GPU RAMDAC, and it can run up to 270-340MHz which is fast enough for most monitors.
These serve a few purposes, but the main reason to mess with them is to position the visible area properly on CRT displays, preferrably in the most geometrically optimal time of the scanout. If the porches are too small, the picture can be cut out or have major distortion.
Porches can be used to hide geometric problems. As an example, some Diamondtrons struggle with vertical linearity on the top part of the picture at high refresh rates. This can be hidden away inside a large vertical back porch, at a cost of slightly lower resolution and/or refresh rate.
Many CRT monitors include position and size controls, however these often have sweet-spots for linearity. Creating a custom resolution with tuned porches can greatly improve the linearity, this is usually the only way to adjust horizontal linearity on even the best CRTs.
Large porches can reduce brightess, however some CRT monitors such as many Diamondtrons have options to compensate for this (Edge Lock). Porch widths can also drive up your pixel-clock, which may impact signal clarity, or exceed your maximum DAC speed altogether.
Zero-pixel porchesThese are used in a few standard resolutions like 1024x768i 43Hz, however many systems and programs (eg. CRU) wrongly consider them invalid. Use with caution.
Early versions of CVT required all of the horizontal values to be
divisible by eight due to hardware limitations of the time. Later this requirement
was lifted. In this editor this limit is enabled by default, but can be
disabled with the H Granularity option.
Most common resolutions are divisible by eight, except 1366x768 - thus you often see 1360x768 and 1368x768 instead. These non-divisble resolutions may cause strange behavior even on more modern systems, my 2015 laptop with a 1366x768 LCD has some funny bugs in multimonitor setups.
Monitors may use these to determine what mode is being displayed. What exactly these convey depends entierly on the monitor and what standards it follows, if any. Many monitors appear completely indifferent to pulse polarities.
Vesa CVT and GTF use them in the following ways:
| Horizontal | Vertical | CVT | GTF |
|---|---|---|---|
| Negative | Positive | CVT Standard CRT | GTF Default |
| Positive | Negative | CVT Reduced Blanking | GTF Secondary |
| Positive | Positive | Not used | Not used |
| Negative | Negative | Not used | Not used |
Similiarly to polarity, the linecount of the vertical sync pulse can be interpreted in different ways, or not at all.
Vesa CVT uses them to convey aspect ratio:
| Vertical Sync Width | Aspect Ratio | Notes |
|---|---|---|
| 3 or less | Not used by CVT | Reserved for existing DMT and GTF timings |
| 4 | 4:3 | |
| 5 | 16:9 | |
| 6 | 16:10 | |
| 7 | 5:4 (1280x1024) 15:9 (1280x768) |
|
| 8 | Reduced Blank Timings v2 | Digital displays understand horizontal pixel counts and can calculate aspect ratio themselves |
| 9 | Reserved | |
| 10 | Non-standard | Can be used for manufacturer specific timings |
Do note that several industry standard resolutions violate these rules, and many displays predate this table.
Your adapter or operating system may still parse these values. I've seen strange behavior where my timings are not actually applied faithfully, instead it appears as something is mistakenly detecting reduced blanking mode and generating large porches instead, likely for compatibility.
Getting interlace to work on modern systems can be tricky. Most Nvidia cards (even ones with native RAMDACs like Maxwells) will only kind of work with HDMI, and as there aren't many or any good HDMI-to-VGA adapters, getting good interlace on a CRT can be impossible.
And even if your system doesn't outright prevent you from applying these modes, you may face other issues, some listed below.
This is caused by DispalyCore, AMD's new linux display engine. For older AMD GPUs,
like Polaris, this can be disabled with amdgpu.dp=0 kernel flag (I discovered this workaround!).
This also disables more modern features, such as Freesync and CTM.
Newer cards, Vega, Navi, etc, require DisplayCore to function. Currently I'm not aware of any way to interlace with these cards, at least in Linux. Passing the frames through an older card equipped with an analog output does allow interlace however, at the cost of slightly more latency than native or adapters.
This seems to be common particularly with modelines generated by CVT. I am yet to figure out what the pattern is, but just modifying vertical porches by one or two values seems to fix it. Sometimes just renaming and reapplying the mode fixes it.
Try different timings until it works. As far as I know, every multisync CRT supports interlace, or to be more correct, doesn't prevent it, as interlace is more of a timing hack that just works on any CRT. But some monitors may be picky about what timings they'll interlace at.
Particularly for older (<1997) monitors, check their EDID for interlaced modes. Copy the timings and edit and experiment on them instead. 1024x768i 43Hz is also worth a try.
Made by your favorite 2hu fan 01/12/2021
Last modified 23/12/2022