Working with Modelines

From MythTV Official Wiki
Revision as of 16:09, 30 March 2011 by Wagnerrp (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Clean.png Cleanup: This article or section may require cleanup. Discuss the issue on the talk page

Time.png Outdated: The information on this page may no longer be relevant to the current release of MythTV, 0.27.3. Please consider helping to update it.

OK, so you want to generate a modeline for X for your HDTV / Projector...

What's a modeline?

It tells your videocard how to draw a picture on your display (monitor/TV/projector etc) Each display has different capabilities. Most obviously they have different sizes and resolutions.

Each modeline describes how to achieve a given resolution.

And why would I care?

When ever you look at something on your display it's shown at a certain resolutions and certain refresh frequencies. Some displays will happily accept video signals for different resolutions and convert them for you - the problem is that this can reduce the quality of the video signal. So ideally you'll get myth or xine to convert your signal once to the right resolution for your tv/projector and avoid unnecessary degradation.

Simply - it can look better.


Important.png Note: Newer Nvidia drivers will not accept hyphen "-" characters in mode names. Change any mode names containing hyphens to underscores in order to avoid errors and potentially, hours of frustration!

My Problem

I have a Panasonic AE100 LCD projector. I want to set it up to get the best posible resolution.

The book tells me it has a native pixel size of 858 x484. It also lists the video modes it supports with various frequencies.

I pick 856 x 480 with the following frequencies:

  • 30.057 kHz Horiz scanning frequency
  • 60.114 Hz Vert scanning frequency
  • 31.500 MHz Dot clock

So the problem is "How do I create a modeline given this input data?"

A google returns a few options (some listed below) the most promising seemed to be videogen.

Being a Debian user a quick apt-get install videogen has me up and running.

man videogen is useful - the most important options being:

-m=XxY 
describes the mode you want a modeline for
-mdc=xx 
sets the maximum Dot-clock of the videocard, not the monitor
-mhf=xx 
sets the maximum horizontal frequency for your monitor
-mvf=xx 
sets the maximum vertical frequency for your monitor
-dvf=xx 
sets the desired vertical frequency for your monitor (I use pal so I'd like it to refresh at 50Hz)

It's not obvious how to use it though, the HTPC suggestion didn't work but after a bit this command produces the desired results:

$ videogen -m=856x480 -mdc=34 -mhf=31 -mvf=61 -dvf=60.114 -nnv
Modeline "856x480" 33.27 856 880 896 1096 480 482 483 505  # 33 MHz, 30.4 kHz, 60.1 Hz

It turns out that only some resolutions are allowed; eg videogen -m=858x480 won't work and gives

argument 2 (-m=858x480) has an invalid parameter

Update: I kept playing with this and found that this javascript calculator gave me more feedback and I ended up with a perfect modeline for a Panasonic PT AE100-E:

Modeline "856x480"   31.50   856 910 918 1048   480 484 485 500  -hsync -vsync

OK, now we have a modeline - time to use it.

Edit your XF86Config-4 file and find the Section "Monitor" part. Now simply insert the modeline generated above. Note the part in "s is the name of this mode.

Now find the Section "Screen" part of the file. There should be a "Display" subsection and that should have a Modes line. This line contains a space seperated list of mode names - you cycle through these when you press Ctrl Alt + and Ctrl Alt - (that plus and minus keys) As always an example should make it easier:

Section "Screen"
        Identifier "[[Proj Screen]]"
        Device     "[[Ge Force]]"
        Monitor    "Projector"
        [[Default Color Depth]] 24
        [[Default Fbbpp]]  32
        [[Sub Section]] "Display"
                Depth     24
                [[Fb Bpp]]     32
                Modes "856x480"
        [[End Sub Section]]
[[End Section]]

Now start X and you should have a shiny new mode.

Useful Links:

Linux HTPC How-to

In particular this page:

http://www.linuxis.us/linux/media/howto/linux-htpc/video_card_configuration.html

provides a useful overview.

Videogen

http://www.dynaweb.hu/opensource/videogen/

While it has been said that videogen is similar to Powerstrip it is actually far from it. Powerstrip can read the EDID data from your monitor and generate a modeline -- videogen can not. What videogen can do is compute a modeline if *you* give it some parameters for your video card and monitor. It's really not that much different than the many web-based modeline calculators but you might be able to get away with providing fewer parameters with Videogen at the expense of loading more software on your machine rather than visiting a web page.

A quick calculator

http://www.hut.fi/Misc/Electronics/faq/vga2rgb/calc.html

It will accept a current modeline as input, and then let you tweak the various parameters to produce a new one.

It needs Front & back porch and sync pulse info - I'm not sure what they are. Can I get this from the h/v frequency?

Working with Modelines by Hand

The Modeline string is not that hard to figure out, but does require some knowledge of how TVs and Monitors work. The basic format of a modeline is:

Modeline "MODENAME" FF H1 H2 H3 H4 V1 V2 V3 V4 FLAGS.
MODENAME: any name you would like (but usually in the form of "640x480@60").
FF: Dot Clock (a.k.a. Pixel Clock Frequency or Bandwidth) (MHz) - How many dots it can output per second.
H1: Width - Number of horizontal pixels drawn to the visible part of the screen (e.g. 720).
H2 - H1: Front Porch - The amount of black pixels drawn to the right of the screen.
H3 - H2: Sync Pulse - The amount of time it takes to start another line.
H4 - H3: Back Porch - The amount of black pixels drawn to the left of the screen.
V1: Height - Number of vertical pixels drawn to the visible part of the screen (e.g. 480).
V2 - V1: Front Porch - The amount of black pixels drawn on the bottom of the screen.
V3 - V2: Vertical Blanking Interval (a.k.a VBI or Vertical Sync) - The amount of time it takes to move back up to the first line of the screen
V4 - V3: Back Porch - The amount of black pixels drawn to the top of the screen.
FLAGS: special stuff maybe necessary for drivers (sync-on-green, sync polarity,
   interlacing, etc)

Because the Dot Clock sets the number of dots to write a second, the times for the Sync Pulse and VBI are measured in the amount pixels that would have been drawn. It draws the visible screen first, then the Front Porch, Sync, and Back Porch.

HHHHHHHHHHH<u>_----</u>_HHHHHHHHHHH<u>_----</u>_HHHHHHHHHHH<u>_----</u>_HHHHH...
0         H1 H2  H3 H4         H1 H2  H3 H4

The vertical is exactly the same, except it uses complete lines to count, rather than individual dots.

Several other important pieces of information can be derived from these numbers

Vertical Frequency = The Dot Clock divided by the total height(H4) times the total width(V4)
Horizontal Frequency = The Dot Clock divided by the total height (H4)

Here's the line I use for my custom NTSC hardware board (720x480@59.94Hz interlaced)

Modeline coryntsci 14.318 720 760 824 910 480 484 492 525 interlace

14.318 MHz dotclock
H:
720    picture pixels
760-720 (40/14.318e6)=2.78us black on right side
824-760 (64/14.318e6)=4.47us sync pulse width
910-824 (86/14.318e6)=6.01us black on left side

Horizontal Frequency is 14.318e6 / 910 = 15.73 kHz (63.556us)

V:
480    picture lines
484-480 (4/15.73e3)=254us black on bottom
492-484 (8/15.73e3)=508us vertical sync pulse width
525-492 (33/14.73e3)=2.1ms black on top
Vertical Frequency is 14.318e6 / (525 * 910) = 29.97 Hz (33.36ms)

It might seem complicated, but it's really pretty simple once you understand what's it's doing. Just a matter of counting dots. The tough part (sometimes) is finding the spec for the video signal (sync pulse widths, etc). If you wanted to move the picture to the left a bit without changing anything else, add 5 to H2 and H3.


Hope that helps some folks

Getting rid of overscan and centering the image

The important thing to understand is that the visible part of the image is only a portion of the overall image you send to the screen. Since HDTVs can be very, very finicky about accepting a signal, it's best to get a modeline they can accept and then tweak it to get the image you want.

So, in my case, my Sharp LC-37D6U would only sync to a 1338x768 signal, but with terrible overscan and the image was far from centered.

The orignal modeline, the only modeline the TV would sync to:

Modeline "1368x720" 79.68 1368 1416 1456 1752 720 722 724 758 # 80 MHz, 45.5 kHz, 60.0 Hz

This, however, left me a black strip of about 3" on the left, and fully 1/3 of the image was lost to overscanning.

So, to move the image to the left, all we do is move the horizontal sync bar to the right. The horizontal sync bar is given by the 4th and 5th numbers in the modeline (H2 and H3 above). That bar always stays fixed, so if we 'move' the bar to the left the picture moves to the right:

Modeline "1368x720" 79.68 1368 1492 1532 1752 720 722 724 758 # 80 MHz, 45.5 kHz, 60.0 Hz

The vertical sync bar is given by the 8th and 9th numbers (V2 and V3), and works the same way: increase the numbers and the image moves up, decrease and the image moves down.

Now that the top left is positioned correctly, we need to fix the overscan. To do that, we tell the video card to put the image into a smaller portion of the overall frame it sends to the TV. We do that by reducing the numbers in the 3rd and 7th columns (H1 and V1 above). Now they read 1368x720 but that's too big for the TV to display correctly. A bit of trial and error produces a modeline where the image is centered correctly, and has no overscan:

Modeline "1368x720" 79.68 1080 1492 1532 1752 680 722 724 758 # 80 MHz, 45.5 kHz, 60.0 Hz

For an excellent graphical and technical explanation, see here <http://www.epanorama.net/documents/vga2rgb/timings.html>.


Troubleshooting modeline validation

If your new modeline appears not to be "taking" in xorg.conf, try starting X with a higher log verbosity setting ie...

startx -logverbose 20

This change will add much more information to /var/log/Xorg.0.log that may assist you in diagnosing bad modelines. Check the log after each restart of X until you get the results you're looking for. The default level of log verbosity usually omits details concerning the validation of user-specified modes.