Configuring Monitors in X

Another Anonymous Coward submitted this question: " Everyone that I know, myself included, has had some trouble getting X11 configured under Linux. If your monitor doesn't happen to "work with X" right off the bat, it seems that you're out of luck. Why is it that I can plug my generic 17" monitor into any old Windows box and get 1024x768, but it won't work at ALL with my Linux box yet I can plug in my Sony Trinitron 15" and it works just fine? We're using the latest version of X, of course. Even Windows 3.1 didn't have the sort of monitor problems that plague X. I see this as being one of the biggest installation headaches for beginners *and* advanced users of the Linux OS." Ah yes: Modelines. I know there are programs that help with this. Which ones do you all suggest?

Actually, I could have sworn we had done an Ask Slashdot on this, but as time passes improvements are made, so I don't mind doing another article on the subject. Just via a quick search on the web, I've found:

• Modeline
• and kvideogen (I'd bet there is a Gnome version of this as well)
• This page that has a simple, web based, Modeline calculator.

So if anyone has tried the above resources, we'd be interested in hearing your thoughts on how they work. If you know of other Modeline resources, please post links. I don't see why X11 has to have the reputation as "difficult to configure" when the tools to do such are out there.

Just a thought: Would including Modeline functionality in configurators like Linuxconf be a good idea?

Comments

Can we leech of Windows?

[specht]

I've done more than my share of pencil and paper work in order to configure X11 (even before the days of XFree86). What still puzzles me is that for Windows you get some .inf files with your monitor that contains everything there is to know about it (at least I assume that's what these files are for, I acutally never opened one).

Would it be possible to just use these .inf files and extract just the information XFree86 needs to configure the monitor?

Re:Can we leech of Windows?

[warlock]

Inf files really don't contain much, here's the relevant bit from my monitor's .inf:

[NOKIA_447Xpro.AddReg]
HKR,"MODES\1600,1200",Mode1,,"30.0-96.0,50.0-150 .0,+,+"
HKR,,ICMProfile,0,"447XP93.icm"

Basically states max resolution, horizontal/vertical freq range and v/h polarization.

I am quite sure that you can get this information easily from all PNP monitors (all recent ones, ie less than 3 year old should support this) simply by talking to them, if your graphics card supports the protocol (again, if you bought it within the last 3-4 years it will).

I think that is what windows does with most monitors anyway, it talks to them, grabs the "name" string (ie Nokia Multigraph 447Xpro) and the relevant stuff (like horizontal/vertical size in mm, polarization, freq ranges etc) and computes the rest automagically. All my monitors seem to work perfectly at the PNP mode, so the .inf files seem redundant, and such a database a waste of time if this can be implemented.

-W

Re:Can we leech of Windows?

[Karcaw]

I put up a web site a while back doing just This. I wrote a little perl scripte to suck the timings out of the WIndows INF files and dump them in a database. I had a lot of response to it initially, but my connection was slow, and I moved since then. I can provide information about it to people, or if someone has web space to donate I can put it back up(I need a Postgress DB and a perl interpeter).

CDDB is a good model!

[Anonymous Coward]

Why not use CDDB as a model for this sort of thing. Keep the monitor specific parameters on line somewhere, and make a generic setup utility that fits on a 640X480 screen which all monitors do. Then pull down the virtual .inf file from the site, compare to a similar site for video, (same site) and then compare them, and present the user with the choices. Why not build on the windows looking interface? Would be a good thing for Andover.net or CNET to provide to the consumer community. John Westerdale

The real trolls

[jmaaks]

Whereas this AC started attacking trolls, he has quickly become what he is accusing... The original poster never suggested X is inferior to Win 3.11. What he said, which is very true, is that the configuration of monitors under X is inferior to Windows configuration.

Personally, I've never had any trouble getting a system working with X (although the monitor may not have been configured as optimally as I'd have liked). But I did think to myself while looking up scan rates that there has got to be a better way. And I think the volume of posters that agree with this issue would underscore the fact this is a real problem, not some phantom issue being raised to suggest "X is inferior to Win 3.11."

My suggestion to people that think like this: Get off your high horse! The original poster was making an honest observation about the quality of X configuration. If we attack posts where people come forward and ask "Why does it have to be this way?", others will be afraid to come forward and point out areas where we can improve. We need to be strong enough to recognize that Linux and its associated applications and tools are not the end-all be-all they can be, and be willing to take this as constructive criticism that points out where we need to start working on improvements.

Modelines?

[redhog]

It is strange that the Xfree86 manual is that bad at describing how modelines works. It even uses the word "magic"! In fact, the SVGATextMode docs are quite good at describing, by example, how they work. The description is in the file creating_textmodes_from_scratch.HOWTO in the SVGATextMode dist.
In fact, modelines aren't as hard as people likes to say. I'l try to explain them roughtly (Please read the SVGATextMode doc before creating any modelines, though, while I won't cover all aspects):
A modeline consists of five parts - name, dot pitch, horizontal values, vertical values and optional parameters. The name is a name to assign the modeline to be able to refere to it later on (In the screen section, for instance). The dot pitch is the number of pixels to draw each second, in Mhz (Note that you should check the abilities of your graphics card before setting this value). Each of the vertical and horizontal part has the same format. They consists of bfour values each - the size of the visible area, the sync start and end and the size of the total area.
A monitor needs some extra "black" space at the end of each line and at the end of the screen. The visible area, plus this "margin" forms the total area. For most monitors, the unviewable area should be about 25% of the visible area horizontally, and about 5% of the visible area vertically.
The sync is a signal sent after each completed line, and after each completed screen, in order for the monitor to start drawing pixels at the same moment as the graphics card starts sending pixels.
Note that the start and end of the sync is stated in pixels, not microseconds (Remember that we know the number of pixels per second). This may crate the somewhat obscure situation of sync start and ends being fragments of pixels (i.g. 800.25).
For most monitors, this signal is to be emitted just after the visible area. The vertical sync should be just a few lines for most monitors. The horizontal sync should be about 2 microseconds in with, or for really low-frequency monitors, somewhat longer (3ms).
The start of the syncs is what centers your visible area on the monitor. You may experiment with adding or subtracting some microseconds to them after calculating them, to center the image nicely.
Note that the start of the sync may _never_ be before the end of the visible are as well as the end of it may _never_ end after the end of the total area!
As a last not, there is one parameter to add at the end of the modeline that I'l describe: DoubleScan. It forces the graphics card to draw each line twice. This will reduce the the resolution to the half vertically. This is to any use mostly when you need some low resolution (For displaying MPEG videos, for instance) on a fixed sync monitor.

Observation

[finkployd]

It seems we have two schools of thought on this.

1) Get your monitor specs, plug 'em in and go with XF86Setup (or Xconfigurator)
2) We need some kind of auto-configure program that does it all for you.

This is the perfect example of the two opposing views for Linux. Do we keep it as it has been, not the most user friendly system in the world (actually requiring computer know-how to use the computer) but very configurable and powerful, or do we make it easy for anyone (Like a Mac) but not as configurable or powerful?

It seems everytime a graphical interface or "program-to-make-linux-easier" comes out, it detracts from the "power" or the stability of linux. I've seen many graphical configuration tools and they all have some kind of tradeoff.

My fear is that when we finally make it easier for the lowest common denominator to use, with it goes it's power and the whole reason we switched from Microsoft to begin with.

Should we even do this? Do we really want to change things to make it easier for EVERYONE (read: computer illerate)?

Finkployd

xvidcalc

[gregbaker]

I've been working on a program recently that does just these calculations. It's still pretty rough, but you can try it if you want (seems like a good opportunity to get some testers).

It gets better refresh rates than KVideoGen or the other calculators I've found.

If you have Perl/Tk, you can run the X version with the command xvidcalc, or the command line version with vidcalc (try "vidcalc -h" first).

I did a lot of work on the caclulations to ensure that the resulting modeline was optimal in terms of refresh rate. You have to enter the specs for your monitor (either in the X interface or a settings file), so it's not for the faint of heart; you should probably look through ESR's VideoTimings HOWTO first.

Let me know how it works for you, ggbaker@sfu.ca.

Greg

Re:Decent solution....

[Tom Christiansen]

My goodness, that was terrible Perl code. At the very least, you should fix the formatting. But it still is, well, icky. As posted, it won't work due to HTML lossage. This should be better, but... oh my. There are still potential bugs, too, due to incorrect detection of error conditions after matches.

Anyway....

#!/usr/bin/perl

unshift @ARGV, 'mga.mon' if !@ARGV && -t STDIN;

while (<>) {
chomp;
if ( /^\[\*/ ) {
s/\r//; # chop ^Ms
($name = $_) =~ s/^\[\*([^\]]*)\].*/$1/;
print "# $name";
/([0-9]+X[0-9]+)[^0-9]/i;
($mode = $1) =~ s/X/x/;
print "Modeline \"$mode\" ";
$pixel_clk=$h_disp=$h_fporch=$h_sync=$h_bp orch=$h_sync_pol=$v_disp="";
$v_fporch=$v_sync=$v_bporch=$v_sync_pol=$i nterlace_enable="";
do {
$_= <>;
chomp;
s/\r//; # chop ^Ms
$go="";
if (/^PIXEL_CLK/) {
($pixel_clk = $_) =~ s/PIXEL_C LK\s*=\s*//;
print !$pixel_clk;
$go="yes";
} elsif (/^H_DISP/) {
/([0-9]+)/;
$h_disp = $1;
$go="yes";
} elsif (/^H_FPORCH/) {
/([0-9]+)/;
$h_fporch = $1;
$go="yes";
} elsif (/^H_SYNC_POL/) {
/([0-9]+)/;
$h_sync_pol = $1;
$go="yes";
} elsif (/^H_SYNC/) {
/([0-9]+)/;
$h_sync = $1;
$go="yes";
} elsif (/^H_BPORCH/) {
/([0-9]+)/;
$h_bporch = $1;
$go="yes";
} elsif (/^V_DISP/) {
/([0-9]+)/;
$v_disp = $1;
$go="yes";
} elsif (/^V_FPORCH/) {
/([0-9]+)/;
$v_fporch = $1;
$go="yes";
} elsif (/^V_SYNC_POL/) {
/([0-9]+)/;
$v_sync_pol = $1;
$go="yes";
} elsif (/^V_SYNC/) {
/([0-9]+)/;
$v_sync = $1;
$go="yes";
} elsif (/^V_BPORCH/) {
/([0-9]+)/;
$v_bporch = $1;
$go="yes";
} elsif (/^INTERLACE_ENABLE/) {
/([0-9]+)/;
$interlace_enable = $1;
$go="yes";
}
} while ( $go );

print $pixel_clk / 1000 . " ";
print "$h_disp ";
$h_disp += $h_fporch;
print "$h_disp ";
$h_disp += $h_sync;
print "$h_disp ";
$h_disp += $h_bporch;
print "$h_disp ";
print "$v_disp ";
$v_disp += $v_fporch;
print "$v_disp ";
$v_disp += $v_sync;
print "$v_disp ";
$v_disp += $v_bporch;
print "$v_disp ";
print $h_sync_pol == 0 ? "+HSync " : "-HSync ";
print $v_sync_pol == 0 ? "+VSync\n" : "-VSync\n";

}
}

It seems like a good candidate to hand to a programmer and say, "how would you rewrite this to make it less of a hack and more aesthetically pleasing as well?".

PNP Monitors and larger modeline databases

[blazer1024]

One big reason that at least newer monitors work with Win9X so well, is that they're plug and play monitors. They just tell Windows what timings they need for each resolution, and then it works. Of course, you need a PNP monitor, and possibly a recent graphics card, but it's still a breeze.

XFree needs PNP monitor support (Unless 3.9.x/4.x has/will have it) as well as some sort of user submitted modeline database for old monitors. I think a user submitted modeline database that could be included in a distro would be great. So that if Joe Average has some crappy no-name 14" (8.5" viewable :) and maybe Jenny Linux Girl tried it before, and submitted the modeline(s), then Joe Average has it easy. What does anyone else think?

Re:Is higher then 1600x1200 resolution possible?

[Doug Merritt]

So.. Is higher then 1600x1200 even POSSIBLE in Xwindows or Xfree86? And if so.. HOW? :)

Of course it's possible. The only reason you have for thinking that "1600x1200" is somehow magic is that your setup has that as its max; you didn't hear anyone else say so, did you? It's the max because you (or the software tool you used) said that was the max.

X/XFree86 is supremely flexible (and wait and see when 4.0 comes out, it's going to be amazing -- not necessarily easier to configure, but even more capable than before).

I configured a max of 1800x1440 on my system, which is the maximum my video card can support with its 250 Mhz dot clock at 70 frames per second. This is made possible by two entries in my /etc/XF86Config file. One says:

# 1800x1440 @ 70Hz, 104.52 kHz hsync
ModeLine "1800x1440" 250 1800 1896 2088 2392 1440 1441 1444 1490 +HSync +VSync

That sets up the possibility of using 1800x1440. To actually use it requires that resolution to appear in a "Modes" line in the Display subsection further down:

Subsection "Display"
Depth 32
Modes "1800x1440" "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
ViewPort 0 0
EndSubsection

Since 1800x1440 comes first in that list, it will be the initial resolution when I start X. Pressing ctrl-alt-PLUS and ctrl-alt-MINUS causes X to change to the next resolution (rightward or leftward, respectively) in that list.

It's quite possible that the tool you used to set up your XF86Config file would have given you higher resolutions if you had asked for them. Or perhaps it thought you had a video card dot clock maximum smaller than what it actually supports; check your documentation.

Make sure you don't exceed the specs on your video card or monitor. If you do, it's extremely likely that one or the other will die young (although extra cooling can help).

P.S. I'm listed as a contributing author for the XFree86 Matrox driver (largely for fixing some really nasty bugs), and I think that setting up modelines by hand is a real pain, and that the various tools from XFree86 and others all have sad shortcomings. Anyone who claims that it's easy either is settling for suboptimum settings, or is bragging the same way that marathon runners claim that running 10 miles a day is easy and fun.

As others have pointed out, Windows users are usually getting 60 frames per second, and very often much lower resolution (and sometimes fewer bits of color) than their hardware supports, unless they actively reconfigure it (and even most engineers never bother), so I don't think Windows is hands-down superior in this area. And to the extent that it at least is easier, that's not a credit to Microsoft, that's a matter of every hardware vendor (like Matrox and Diamond and SIII etc) writing drivers and configurations for Windows. The more they do the same help for Linux, the easier things will get for us.

Why 'standard' resolutions?

[Mawbid]

At one time, I want looking for a modeline generator and found this one. I was surprised to see all sorts of weird resolutions in the results, like 1448x1086. Much to my surprise, that one actually worked on my monitor, which isn't rated for anything higher than 1280x1024. So, the question is: Why doesn't anyone talk about or offer resolutions other than the familiar 1024x768, 1280x1024, 1600x1200, etc? It doesn't seem there's anything magical about these numbers at all.
--

It's ironic . . .

[alhaz]

that XFree86 got this reputation due to shortcomings in the "easy" configuration programs, such as XF86Setup, XConfigurator.

I haven't used Corel, haven't used Caldera in a while, haven't used RedHat 6.2 either, so i can't speak for the latest of any of those.

But the kicker was, even if you did know the sync range, if you used the most popular consumer distribution, RedHat, you were shit outa luck unless it was on their list.

For those lacking an irrational fear of linearly-scripted text mode configuration, xf86config has always allowed you to enter a custom sync range, and it's calculations are pretty decent.

SuSE's x configuration app, SaX, is a TCL/TK based graphical configuration app that tends to do a great job, too.

The only real problem is getting ahold of the sync numbers. I sure wish manufacturers would just print it on the back of the monitor. I tend to use a fine point perminant marker to scribble it over the FCC info on mine, in case i have to reinstall.

But there are several ways of getting those numbers. I'll suggest a few.

RTFM: this is the most obvious. I've got no sympathy for you if you've got the manual and insist that you shouldn't have to read it.

Windows: A lot of Win9x video drivers will spit out the sync range if you get into the "advanced" display settings. Handy if you use dual boot. I know that nVidia's drivers do this, for one.

deja.com: somebody else out there probably already asked for help with it. make sure you tell it to search "all" messages. it's idea of "recent" is getting pretty freakin recent these days.

manufacturer web site: They just might have had the presence of mind to publish it online.

altavista/metacrawler: Someone else might have too.

email the manufacturer: if you're lucky they might respond.

Steal a manual: if it's a current model, CompUSA or similar might have one on hand they'll let you photocopy. Even if it's not, a store that sold it locally might have the specs on hand in their service department. I know when i worked on the service end of the industry years ago I hoarded that information. Believe me, the tech will sympathise with your plight. Imagine how they feel when someone dumps something on their table and says "make it work" - they know what it's like to pray for documentation.

I agree with a previous poster that it would be really nice if we could just parse a windows "monitor driver" .inf file for the info we need, does anybody here know what'd be involved in doing that?

Re:Decent solution....

[Tom Christiansen]

How the fuck did you get the formatting so nice? Thanks.

Now, isn't that a silly question-- by using a perl program, of course. Were you expecting anything else? :-)

Here it is, having been run on itself:

#!/usr/bin/perl -p
#
# code2html - convert code to html for posting to slashdot
#
# tchrist@perl.com
# Sunday, December 19th, 1999

BEGIN { print "<TT>\n" }# and the spirit of awk...

# first kill all the tabs
1 while s{ \t + }
{ " " x (length($&)*8 - length($`)%8) }ex;

# then the four standard naughty bits
s/&/&amp;/g;# must remember to do this one first!
s/</&lt;/g;# this is the most important one
s/>/&gt;/g;# don't close too early
s/"/&quot;/g;# only in embedded tags, i guess

# make lines break where they should
s/^\s*$/<P>/ || s/$/<BR>/;

# make sure spaces aren't squishticated so we
# can do indentation and properly align comments
s/( {2,})/'&nbsp;' x length($1)/ge;

END { print "</TT>\n" }# ...shall be with us always

Also, if you're going to preview, make sure you hit the back buttand submit from the pre-previewed part. Slashdot has a bug on its escaped stuff otherwise; you lose the escaping after the preview. So look, but don't launch. There are other bugs in the slashdot presentation code that I'd really love to find (my nbsp code above is working around it by looking at only long stretches of spaces), but I don't have a recent copy to inspect.

The Straight Dope

[ewhac]

Okay, I don't have time to write a full treatise, so here's a quick overview of all the sTUfF involved. For the record, my job is writing graphics drivers for BeOS.

There are several constraints which need to be observed. These are:

• Minimum/maximum pixel clock rate of the card,
• Minimum/maximum horizontal rate of the monitor,
• Minimum/maximum vertical rate of the monitor.

Typically, the graphics driver will constrain the pixel clock rate, so the only thing left to worry about is monitor scan rates. The scan rates supported by your monitor are printed in your owner's manual.

Modern monitors also support DDC (Display Data Channel), which is a funky serial protocol to get identification and configuration information out of the monitor. The original DDC spec provided only for transmitting a unique monitor ID. The ID was supposed to be looked up in a database which would contain the monitor's min/max scan frequencies and other characteristics (can you say C:\WINDOWS\INF\MONITOR*.INF?). A more recent revision of the DDC spec now supplies these frequencies directly, as well as gamma characteristics and other cool stuff. Neither XFree86 nor BeOS support DDC yet.

Trivium: Absolutely every monitor out there will support 31.5 KHz horizontal, 60 Hz vertical. Unfortunately, this is only useful for 640 x 480. That's why Windoze defaults to this when it can't identify your monitor or graphics card; it knows this will work in any case.

Once you have a mode line for a particular resolution, you can not simply tweak the pixel clock. Sync timings vary not only by resolution, but also by scan rate. This is because the horizontal sync pulse is not simply a percentage of total horizontal time; it needs to be of a fixed duration, regardless of the scan frequency. If you stray outside the sync pulse requirements, the monitor's flyback transformer can overheat, shortening the monitor's life (and possibly killing it in ugly ways).

There are three ways "The Rest of the World" generates mode lines. One is via a direct DDC probe as outlined above. Another is to use the official mode table provided by VESA. This table contains fixed sync timings from 320 x 200 all the way out to 1900-something. Monitor manufacturers are supposed to make certain that their monitors respond well to these modes. When compiling their BIOS mode tables, however, some graphics card manufacturers, however, will make minor alterations to the VESA table, usually to the HSync and HTotal parameters. I've never discovered why they do this (except that if you don't, the graphics will come out looking funny in some cases).

The third way is to use the VESA GTF (General Timing Formula). This formula takes the following parameters:

• Desired display resolution,
• Desired (vertical scan rate OR horizontal scan rate OR pixel clock frequency)

From this, it will compute a mode line that will work on all modern monitors, and most old ones (too old to support DDC). The formula is rather ugly, involving a square root somewhere, and I don't have it in front of me.

Copies of the VESA mode tables, GTF, and DDC specs can all be ordered from VESA. I don't know offhand what, if anything, they charge to print up and send you a copy.

XFree86 should at least use the VESA mode table as a starting point for mode lines.

Schwab