Configuring Monitors in X 408
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?
Xconfigurator (Score:1)
Can we leech of Windows? (Score:5)
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?
X modelines make me ill (Score:1)
I'm sure someone will tell me now how understanding how modelines work is good for the soul, kind of like self-flagellation, and I should spend 3 or 4 hours doing that, instead of my job. Let me issue a preemptive "bite me" to anyone inclined to recommend that.
Corel Linux (Score:2)
Re:Corel Linux (Score:2)
- Robin
How many problems are there? (Score:2)
Re:Corel Linux (Score:1)
Is the code that does this GPL'd? If so, somebody should incorporate this into the existing X configuration tools so that newbies won't get turned off by the complexity (and headache) of configuring X. (I know what it's like... I'm using a barely-supported chipset SiS 6326. I've suffered with using X at 800*600 since XF3.3.3. Apparently XF3.3.5 supports it but on 3.3.5 I still can't get XAA to work *at all*, can only use BitBlt but with no ImageBlt.)
Re:Corel Linux (Score:1)
RedHat 6.1 does the same thing. As long as you have a monitor that knows how to answer that request, you are fine. But often you will want to use another resolution than the standard ones, then you are stuck with modelines again.
My favorite:
Modeline "1368x1024" 150 1368 1400 1516 1712 1024 1027 1030 1064
Re:Can we leech of Windows? (Score:1)
Re:Corel Linux (Score:1)
One thing I must add about Corel Linux, while personally I think it's too sugar coated (born Slack, die Slack), it's a great distribution for beginners, very easy to install.
Re:Corel Linux (Score:1)
Personally, I think the issue is driver code that every monitor manufacturer gives out on floppy disks that plug right into a window system. I think the idea that a previous poster had of trying to gather the appropriate info from those driver disks is a great idea.
XFree86 3.9.15 and modelines (Score:1)
Re:Xconfigurator (Score:1)
There are two things that come with Red Hat, that are GPL'd, that I wish other distros would use: Xconfiguration and sndconfig. Those two programs are completely awesome!
Re:Corel Linux (Score:1)
Slackware 7 comes with VESA FBDev installed and setup correctly out of the box. If you're willing to take a small performance hit in X, this allows you to use pretty much whatever graphics card you like.
I never did find it difficult to set up the monitor by hand myself though...
(Off topic, unrelated.. Some guy got moderated down as a troll for saying he had no problems with xf86setup. What's up with that mod?)
Re:Can we leech of Windows? (Score:1)
Re:Xconfigurator (Score:1)
why is sndconfig left out of install?? (Score:1)
Why does the red hat installation not mention it at all? They could at least mention it, and say "it doesn't work for every card but would you like to try to configure your sound card now?"
I was fortunate enough to remember the sndconfig command from a slashdot forum discussion a long time ago. Otherwise, I wouldn't have known about it at all.
X configuration is okay (Score:2)
troll? seems unfair (Score:1)
Toshiba monitor info button (Score:1)
My 17" monitor (Score:1)
Monitors..... (Score:1)
Re:Can we leech of Windows? (Score:1)
Errr. (Score:1)
Re:Toshiba monitor info button (Score:1)
VESA DDC should eliminate this, or no? (Score:1)
Is this a case of Linux distros just not shipping with support for this? It seems if it were as simple as a querying the BIOS somehow at bootup, we would have this issue licked.
Excerpt from Windows registry for Vision Graphic 19" monitor:
.
.
.
MaxResolution 1600x1200
MonitorRanges 30-95,50-150,+,+
EDID 00 ff ff ff ff ff ff 00 28 ae c7
DPMS 1
.
.
.
The only missing component is knowing the limitations of the video board and how to set it.
SAX is somewhat idiotproof :) (Score:1)
Related question. (Score:2)
I was wondering if there is a way to use this to create a dual-headed display?
Another useful online tool (Score:2)
Get your monitor manual and look up the parameters (max hor/vert refresh rate, etc). I was able to get 1536x1152 @ 95Hz for my Iiyama, veeery nice...
-adnans
Re:Xconfigurator (Score:1)
never been able to get Xconfigurator to give me
an acceptable setting, something that would not
give me a black screen or no sync.
Sax works for me.
As for sndconfig, same thing. I ended up
buying the commercial sound driver.
sndconfig is only good for a handfull of sound
cards and doesn't recognize a lot of sound cards.
xf86config (Score:2)
I have installed it on about half a dozen systems, with quite different monitors (from a very bad 15 inch to at quite nice 20 inch trinitron.)
I have never had a problem, BUT I have ALLWAYS LOOKED UP THE SPECS for the monitor and entered the CORRECT values for both V and H refresh.
Perhaps the key here is to RTFM.
-Peter
PS: This is intended as a serious post. Just because I use the phrase RTFM does not make it a troll!!
Re:Corel Linux (Score:2)
xf86config (Score:2)
Re:SAX is somewhat idiotproof :) (Score:1)
CDDB is a good model! (Score:4)
Re:xf86config (Score:1)
Fixed Frequency monitor (Score:1)
Re:xf86config (Score:1)
The solution I used? I had a copy of muLinux, and knew it worked because I had used it on the laptop earlier... I edited the config (ignoring the big DO NOT EDIT BY HAND) to put in the values in muLinux's config, and with a little more fiddling I had a working 256-color config. Later I tempted fate by setting up the SVGA driver by hand to get more colors.
That sort of thing, however, is not something your average user would do... Even though I'm fairly good with computers, I was still nervous about messing around with those values (I've only been using Linux for a couple of months, and had no clue what some things meant in the X config file).
More Generally... (Score:1)
Also, once we have XF86 4, we could do similar with the driver source (even having precompiled binary drivers for each processor type -- since the loading mechanism is independant of the OS...)
John
Re:Errr. (Score:1)
Re:Errr. (Score:1)
Re:troll? seems unfair (Score:2)
Here is the setup I use for 1600x1200 on my V775 monitor.
Else, break out the calculator and look at the XFree86-Video-Timing s-HOWTO [linuxdoc.org] and customize your own (and possibly exceed the performance limits of your monitor!) If you go beyond specs, the driver circuits can consume too much current and overheat. Not cool.
The real trolls (Score:4)
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.
Dual headed? (Score:2)
Re:xf86config (Score:1)
Yes, RTFM will help. I read the original guidelines on doing the calculations back in the mid-90's. It was annoying, but I got it working.
These days, I pretty much select my monitor from a list and go. But I am using one of the monitors that someone else has already gone to the trouble of working out the configuration for. I think Linux has reached the point where there is a demand for somebody to do this packaging of the information. Somebody need to have a lab where they generate and test the configurations for various monitors.
Modelines? (Score:5)
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.
Really strange... (Score:1)
I installed Red Hat 5.2 as a clueless newbie, but was pleased to find that the video probing went quite well, letting me see a rather pretty display of 1024x768 on my 17". Clueless newbie that I was, however, in a few days I was so confused and thought I'd gunked up so much that I formatted the partition and installed Red Hat 6.
6, however, DID NOT support my video. I ended up reinstalling 5.2 and then installing 6 on top of it.
Now I've learned my lesson--just use the XF86Config file from 5.2 instead of a whole new installation--but this puzzles me. Why would an earlier version support something that a later version didn't?
Re:VESA DDC should eliminate this, or no? (Score:1)
Re:Corel Linux Nope (Score:2)
Caldera, OTOH, gave me a much more solid 80hz, since it actually knew what my (Philips) monitor was capable of.
RedHat (Ok, Mandrake) gave me 75hz, since it didn't know my monitor, but I gave it the ranges for refresh and it decided that was good enough.
Two things to remember and no problems... (Score:2)
2. Know your monitor specs and specify them correctly when the xf86config program asks
When I say monitor specs I mean - the ranges in khz (horizontal scan rate?) and hz. (vertical refresh rate) xf86config will ask questions like: I have a monitor that can do 1024x768 @ 70Hz, if this is what it can do in Windows then use it.
I think most of the problems experienced by Linux users are probably from trying to get 1152x864 and other Sun (or "non-standard") modes to work on monitors that were not designed for that.
I wrote my own modeline a long time ago to get 1152x864 on my ADI Microscan 4v - but I wouldn't recommend it now, especially as my Microscan now plays up a fair bit.
Re:SAX is somewhat idiotproof :) (Score:2)
##
## -----> sax -----
##
Filename: sax.rpm
Label: SuSE advanced X Configuration
...
Description:
SaX steht für ( SuSE advanced XF86-configurator ) und ist eine alternative zur herkömmlichen X Konfiguration.
trans:
Sax stands for ( SuSE advanced XF86-configurator) and is an alternative to the regular X Configuration
As for the Troll post(s):
I find the X interface far superior to whatever the M$ world offers
- OS can run without it,
- choice of different window mangers,
- mode switches between resolutions,
- no-nonsese one-click cut and paste,
- different functionalty on every of my three mouse buttons,
- interfacing to other X-servers over network allowing me to xhost other machines.
It has the feel to be made for the purpose of providing functionality rather than marked share and dominance - and it's XF86Free
Hey, I ran across a good one:
The best remote admin tool for NT is a car
(In Network Intrusion Detection by Stephen Northcutt)
Is higher then 1600x1200 resolution possible? (Score:2)
I have a Diamond V770 Ultra (TNT2-Ultra) with
32megs of RAM. I also have a "21 monitor which
claims to have a max resolution of 1600x1200.
BUT..
In Win98 I run at a res of 2048x1536.
Yep. Thats right.. 2048x1536. Thats the MAX
my video card will go, and my monitor can handle
it.. and I do notice a big difference between
that res and the common 1600x1200.
My monitor is a Hitachi CM751U.. Its specs are:
Horizontal - 31-95 kHz
Vertical - 50-160 Hz
Video Clock Frequency - 200 Mhz (typical)
Resolution - Horizontal - Up to 1,600 dots
Vertical - Up to 1,280 dots
My question is though.. I always see the MAX
resolutions for Xfree86 at 1600x1200. Can't
it go higher? I'd love to have the same
resolution in Xwindows. I thought perhaps maybe
the Xconfigurations tools out there just maxed
out at 1600x1200, but perhaps by manual configuration a higher resolution might be gained.
I really HATE modelines though and would rather
not try to figure it out myself.
So.. Is higher then 1600x1200 even POSSIBLE in Xwindows or Xfree86? And if so.. HOW?
Thanks,
-Matthew
Technetos, Inc.
Re:Can we leech of Windows? (Score:3)
[NOKIA_447Xpro.AddReg]
HKR,"MODES\1600,1200",Mode1,,"30.0-96.0,50.0-15
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
-W
Comment removed (Score:4)
Re:How hard can it be? (Score:2)
I've used many monitors under X, some of them with brand names that sounded like they were being manufactured by a fly-by-night operation in some East Asian country I never heard of. I never had a single problem getting X up and running, except for the requisite problems setting up *any* program under Linux when the kernel is at (or less than) 1.0 and you've never used any UNIX but SunOS (and only as a user).
Here's how you find the specs on your monitor:
Here's how you configure X with the info you gathered:
Remember, if you're working with obsolete junk, like $25 monitors you bought at a computer show, BE CONSERVATIVE. Don't try it push it and run at 1024x768@72Hz, even though you think that's the base minimum any monitor should support. Not every monitor is created equally, and some used monitors are over ten years old! Stick with standard VGA and VESA standard modes until you *know for a fact* that your hardware can do better. Call up Compaq, Digital, Sony, etc, and ask them what model monitor you've got. Measure the monitor's height, width, depth, diagonal viewable screen size, and weight. Maybe they might even spare a tech if you're polite.
Re:Dual headed? (Score:2)
Using multi-headed framebuffers [demon.co.uk]
Multi-Hea d Mini HOWTO [alaska.edu]
Yes! (Re:The real trolls) (Score:2)
In other words, some people need to remember that the the strength of open source is not that programs don't need to be improved, but that they can be improved. Any time someone says: "Doing foo is easy, just do:
I always think, then write a program to perform steps 1.,2.,3. since that's the kind of thing computers excel at; then we can leave the stuff like drawing, writing, communicating, playing, etc. to people, who excel at that sort of thing.
The fact that something is 'simple' to do does not make it easy for the average person. The thing that sets geeks apart from normal people is the ability to see things compartmentalized into their most basic components. I think most people think a great deal more holistically.
Chris
xvidcalc (Score:5)
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 [linuxdoc.org] first.
Let me know how it works for you, ggbaker@sfu.ca.
Greg
Re:Decent solution.... (Score:3)
Anyway....
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?".Re:Corel Linux (Score:2)
Back to the topic, anyway. Corel s***d up my XF86Config. It launched KDM right away before reassuring that the graphics is properly tuned (I did a standard, idiot-proof instalation! starting with formatting the disk - well, *a* disk I didn't need). I have a quite old SVGA monitor and a S3 PCI graphics card. I didn't look at the config file produced by Corel (just replaced it with the proper one), but it was certainly flawed.
Regards,
January
Another modeline utility (Score:2)
http://pegasus.rutgers.edu/~elflord/unix/modeline/
Re:X modelines make me ill (Score:2)
NEC MultiSync 5d -- help me! ;-) (Score:2)
Re:Corel Linux (Score:2)
Gotta cut the number of hours I work...
- Robin
Xconfigurator (Score:2)
PNP Monitors and larger modeline databases (Score:3)
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
Re:Can we leech of Windows? (Score:3)
Re:CDDB is a good model! (Score:2)
Mirror the database on an install CD.
Re:Is higher then 1600x1200 resolution possible? (Score:4)
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.
Re:Can we leech of Windows? (Score:2)
Why 'standard' resolutions? (Score:3)
--
It's ironic . . . (Score:3)
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"
Web Database of Modelines (Score:2)
---
Re:Decent solution.... (Score:4)
Here it is, having been run on itself:
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.Configuring Monitors in X (Score:2)
Thus, you may have "1024x768a", "1024x768b",
I built my database five years ago and I have never come across the monitor that I could not configure in five minutes. What I need to know is what the monitors capabilities are (approximately) and I immediately can take the appropriate modelines from my list.
It is not that dificult once you get an idea of what "classes" of monitors are out there. Believe me there are not that many -- for 99.9% users it is five, maximum six types.
With this approach I had to write modelines only twice -- and those were special modes not suitable for desktop X and not in any databases I could find. One mode was for full screen TV and the other for full screen mpeg. Those were the only cases that I had to learn how to write the modes.
In general, I find X approach more flexible than Windows', since it lets you to define modes manually. When similar multiple modes exist, I can try them and chose the one best looking. I usually have to redefine modes manually after the installation, because I'm not happy with the results. The older tools tended to put the most conservative modes while the latest tools (like latest Xconfigurator form RedHat) put those that have the highest refresh rates, maxing out the monitor. In either case the results were not acceptable and there were not enough choices for me.
X can be very flexible here with just a little effort and understanding from the user side. For example, my modes declaration in Display section begins with "1280x1024f" and ends with "320x200" going thorugh many modes in between. Which windows computer can do that? Another example is my home monitor, which is a cheep 17" allowing to do only 1280x1024 at 60Hz, which is unusable. In windows, I can use it only as 1024x768 (since the only possible selection above 1024x768 is 1280x1024). In linux under XFree, however, I am happily using it as 1152x900 at 70Hz. And I did not have to write that mode either. I just took it from a database of modes. There are other monitors out there (there were much more in the early days of Win95) which when failed to be probed by Windows will work miserably or fail to work at all.
The stuff you mention is a problem, no doubt. But it is not that difficult to master. You need to understand that due to microsoft monopoly and its proprietry standards it is very easy to test monitors under windows (because vendors provide the specs and make their monitors windows probe friendly) and very difficult elsewhere. This situation is going to change rather quickly with expansion of Linux, erosion of Windows monopoly and a bunch of Linux friendly hardware available.
I can e-mail my mode database to anyone who is interested or post it if there is enough demand.
Re:Is higher then 1600x1200 resolution possible? (Score:2)
I'm surprised no one mentioned this before..
I have a Diamond V770 Ultra (TNT2-Ultra) with 32megs of RAM. I also have a "21 monitor which claims to have a max resolution of 1600x1200.
BUT..
In Win98 I run at a res of 2048x1536.
[...]
My monitor is a Hitachi CM751U.. Its specs are:
Your Horizontal sync limit is going to kill your refresh rate here. 95000 lines/sec divided by 1536 lines per screen leaves you at a max of 61.8 Hz. After you take into account the extra time needed at the end of a scan of the screen, you'd be lucky to make 60 Hz in that mode without exceeding your monitor's horizontal sync limit. I recommend you check what refresh rate that Windows 2048x1536 mode is running at, and if it's more than 60 Hz -- well, you've been warned.
The situation (Score:2)
MS-Windows, in contrast, defaults to a "lowest common denominator" that works nearly everywhere, but typically gives you a 60 Hz vertical refresh rate. 60 Hz is pretty lousy, and can lead to eye injury. OSHA recommends at least 72 Hz for safe computing.
If you have an OEM monitor information file (.INF), you can clue MS-Windows in to the maximum frequencies for your monitor, and MS-Windows will do what XFree does -- pick the best possible mode from a list of pre-configured "stock" modes.
Note that MS-Windows has no built-in way of manually entering your monitor specifications, like XFree does. Thus, if you do not have an OEM
As usual, it comes down to a matter of OEM support. Many OEMs support MS-Windows, thus it is perceived as better. Fewer OEMs support Linux, thus it is perceived as inferior. In reality, this reflects the quality of the OEMs, not the operating systems.
Case in point: I have a 19-inch Samsung SyncMaster 900p monitor. To set it up under MS-Windows, I downloaded an
There are things that could be done to improve the situation under XFree. One is to write a converter program which will extract needed the information from an
The other thing to do is modify xf86config, Xconfiguration, and the other dozen or so X configuration programs to actually prompt for and use said
We also need to include stock mode lines for higher resolutions, as many monitors are capable of more then 1280x1024 these days.
Just my 1/4 of a byte.
Ahh, I see... (Score:2)
Re:Why 'standard' resolutions? (Score:2)
It's probably just a matter of what resolutions they've done QA on and are known to work well.
No manual? No problem! Go to the FCC... (Score:2)
2. Go to http://www.fcc.gov/oet/fccid
3. Punch the FCC id in.
4. Read the specs...
Is this fool proof? No. For example, read the results from searching on evokd-1910t. In this case, it's a wonder that the request for an FCC ID was accepted.
For those who think only idiots have problems... (Score:2)
Documentation problem (Score:2)
For instance, try to figure out how to change your monitor resolution in less than an hour, starting from "resolution" or "monitor".
Re:Are modelines really necessary? (Score:2)
Unlikely, given that the free-software BSDs tend to use as their window system, err, umm, XFree86.
This is largely not a Linux issue, it's an X server issue; Accelerated-X, say, might do better, but, given that my monitor accepts a bit stream rather than an analog signal, I can't really say, based on my experience with Accelerated-X on my monitor, how it handles glass-bottle displays.
Wrong question (Score:2)
The question is "Where do you start?"
Consider the appliance user, with his new Linux install. He just wants to adjust the resolution of his monitor. He looks for a menu item. No menu item. He looks in the man pages. No help there, either.
Even if he figures out that he's got to twiddle a file himself, how the HELL is he supposed to know that the magic word is "modeline"?
And if he does find out that word, just try looking it up in the man pages.
The problem isn't that it's hard to adjust the resolution (though that is a problem, too). The problem is that the newbie has no obvious way to find out how to do it.
Windows and Mac both make it easy. Linux stock distributions make it arcane. So the new Linux user is stuck with some minimalist stock install resolution until he fights this battle for himself or gets help from somebody else.
THAT's why Linux gets a rep for being hard to use, requiring a geek under the hood at all times.
Re:Decent solution.... (Score:2)
And for those who'd rather not install Perl, here's a Python translation (having been run through itself, of course):
#!/usr/bin/python
#
# code2html.py - convert code to html for posting to slashdot
#
# Sunday, December 19th, 1999
import re
from string import *
from sys import *
print "<TT>"
ent_re = re.compile('[&<>"]')
spaces_re = re.compile(' {2,}')
def ent_sub(m): # replaces forbidden chars with HTML entities
return '&' + {'&':'amp', '<':'lt', '>':'gt', '"':'quot'}[m.group(0)] +';'
for line in stdin.readlines():
line = expandtabs(rstrip(line))# strip trailing spaces and expand tabs
line = ent_re.sub(ent_sub, line) # convert entities
# terminate lines correctly
if len(line)>0:
line = line + '<BR>'
else:
line = '<P>'
# make spaces non-breaking, and print the line
print spaces_re.sub(lambda m:" "*len(m.group(0)), line)
print "</TT>"
Note that you need to use "HTML Formatted" mode. In "Plain Old Text" mode you'll get extra newlines. That seems to be true for Tom's version as well, but I'm not sure. I don't have Perl installed on this machine...
This is also not a direct translation. The Perl version converts the "naughty bits" one after eachother. This version converts them simultaneously, so we don't have to be so careful about the order. Also, this version converts all (non-trailing) spaces to nbsp's, to prevent word wrap from kicking in (bad for lots of code, including Perl/Python/sh comments...).
Finally, both versions of the script don't prevent Slashdot from wrapping long lines. This can be a problem for languages that care about newlines. This includes Perl (imagine a comment getting wrapped at the wrong point...), Python, most shell scripting languages, C and C++ (preprocessor directives), Java (again, the comment issue), most config file formats, etc., etc...
BTW Tom, why is the userid part of your email address only 7 characters long? I thought most systems that truncated did it at 8 characters.
The Straight Dope (Score:4)
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:
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:
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 [vesa.org]. 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
Re:Can we leech of Windows? (Score:2)
0) Go find the
1) look in your video card inf file. For instance, mine is called "nv4agp.inf", for an nvidia agp TNT. There should be some similar lines to:
HKR,"MODES\8\1152,864",,,"60,70,72,75,85,100,12
These are the vertical refresh available for your video card at 8bpp, at resolution 1152/864. By going over to the microsoft site, I was able to determine that any higher color depths that don't have a listing default to the same thing for a lower color depth, for instance, i think the following more or less blank line means that for 16bpp the vert sync rate is the same as 8bpp:
HKR,"MODES\16\1152,864"
2) Now look at the
[CM751.AddReg]
HKR,"MODES\1600,1200",Mode1,,"30.0-94.0,50.0-16
I _think_ that means that my highest resolution supported by my monitor would be 1600x1200, my horizontal sync frequencies are 30-94 and 50-160 (this is atually correct, as stated in my manual).
3) Now you know manufacturer specified vertical frequencies for your video card, and the maximum vertical and horizontal frequencies for your monitor. Now use this information in one of the autoconfigure utilities such as "modeline", or that web page mentioned in the original article. The web page seemed easiest and worked best for me. I just plugged into the web page the resolution I wanted, and then kept feeding it higher and higher vertical frequencies as per my video card inf file until I maxed out my monitors horizontal refresh range. Be careful not to plug any vertiacal frequency past the vertical range of your monitor that you found in your monitor inf file. Similarly, make sure that the figured mode line doesn't go over the horizontal frequency either (the web page reported what the horizontal freq was for the calculated mode line but the "modeline" utility didn't, so you have to do it yourself. go look in the video tuning howto).
Seems to me that it would be easy enough for installation programs to do this for you from windows inf files if you have funky configuration. If _windows_ can do it, linux should be able to. All the info is right there!
CAVEATS!!!: You can burn out your monitor if you overdrive it. Don't do it if you're scared of doing so. I've been messing around with this stuff for a while. Also, when I tried to push my monitor to the highest limits of what it was supposed to do, it usually doesn't do what its supposed to. For instance, I usually had to settle for a vertical refresh of 85 instead of 100, even though my monitor and vid card are supposed to be able to do it. Your mileage may vary.
I often don't bother with monitor info (Score:2)
I figure it's not worth the hassle trying to track down old monitor specs, so if there is nothing obvious, I just make one up that has very generous ranges. I can then read off the actual frequencies from the console output of the X11 server. If a monitor were to die using that procedure, well, they have gotten pretty cheap and I probably didn't want it anymore anyway. But after installing Linux with dozens of different monitors, so far, I have not had a problem.
Of course, if Linux wants to take over the desktop, I think a more plug-and-play approach is needed. IT departments want easy installation on a variety of hardware.
Re:Observation (Score:2)
I don't think that making the X config easier to do is neccessarily "dumbing-down" Linux. Quite the opposite.
To me, getting an optimal X config is not terribly difficult, but it is pure drudgery from where I sit. I, for one, would love to have a widget that could suck the info from a .inf or a cddb-style thing and use that as a basis for building an XF86Config file's modeline and monitor entries. Someone else mentioned also querying the VESA stuff from the monitor directly. I'm all for it.
If these sources of information provide what's needed to assemble optimal configs for the standard resolutions and bit-depths, great. Then, if I want a funky resolution, I can go edit the XF86Config myself.
In a word, yes.
Linux must make some progress toward becoming mainstream. That's ok, since we can still have it as raw and unfiltered as we want, but if my mom is ever going to have a machine with Linux on it, it must have some provision for making it simple to get working. To avoid doing so means marginalizing Linux, and that would be tragic.
Re:Can we leech of Windows? (Score:2)
-W
Re:1152x864 < 2^20 (arithmetic) (Score:2)
However, users should also note that Video Card memory that you don't use for screen data is now usually used by the low-level acceleration functions of the card, and that if you don't make the memory available to the card then these functions won't be available to it and the card might start to run like a dog for you.
Still not on the right page. (Score:2)
The problem is that they get some minimal default configured. Now that they're up, they'd like to use the whole screen.
How do they CHANGE it?
How do they FIND OUT how to change it?
Pretend you know NOTHING about X. You're fresh from Mac or Windows. You have a machine that has a multi-megapixel monitor running 640x480 and want to make more use of it. Your old environment had a graphic monitor config tool, that's what you're used to.
What do you do?
Hunt for a tool. No tool.
Hunt for online documentation. Try "monitor". Try "resolution". Nothing.
Now what?
Re:not true (Score:2)
WHAT readme file? They're up and running at 640x408 and have no CLUE about README files, let alone the one associated with the X windows system.
go to xfree web site and read the jump start guide.
So what's this "xfree"? Where are they supposed to learn:
That there is something called "xfree" that has something to do with their screen resolution.
That they should go to a web site to learn how to configure it.
We are talking appliance user here, not programmer.
It comes back to this: The online documentation MUST quickly vector the naive user to the answer to the question, or the system is "hard to use". For screen resolution questions, Linux distributions don't do this.
60 Hz? Good God! (Score:2)
At any rate, the "Max" refresh rate is probably just the manufacturer's recommended maximum rate. The warranty might well be void if you drive it at anything more than that.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
Re:Modelines? (Score:2)
Re:Linux is Dinasaur OS (Score:2)
It's a fair point that visual configuration tools are pretty non-existent for Linux. But given the relative youth of Linux as a desktop OS and the speed of development in most other areas I can't imagine this situation will exist for long.
But that's almost beside the point, which is that the Linux way of providing configurations as text files if you want them is inherently superior to the Windows way. Simplicity, in this case, is a good thing. In Linux it is possible for third party vendors to write sophisticated configuration tools without having to conform to Microsoft's API of the month.
Linux will evolve to contain all the visual config tools that you desire, and when it does Windows will have little left to recommend it to a novice. Then Windows will be left as your dinosaur OS. And when this happens, experienced sysadmins will still be able to dip into the raw config files and activate settings that nobody though to include in a pretty dialog box.
Re: (Score:2)
Re:Decent solution.... (Score:2)
Re:Decent solution.... (Score:2)
Second off, why should I bother to jam on Python's faults? I see no profit from that.
I'd rather discuss the discrete advantages and disadvantages of your particular program--which, by the way, doesn't bloody work.
Nope, I'm sorry. That's not true. I don't know whether you're lying or simply wrong, but in any event, your fudding is unbecoming of any serious cyberlinguistic researcher and analyst.Badly written code is notorious for being unmaintable irrespective of the implementation language. Fuzzy thinking and sloppy coding makes any program a nightmare. A software professional has been trained in ways that your common CGI hacker has not.
Perl is very accessible to these untrained but eager nonprofessionals just trying to get their jobs done. They shall forever come up lacking when held to the same standard as you would hold a softare design engineer. But they, too, have a place in the world. It's officialyy perfectly ok to speak "Perl baby talk". That's what they're doing. Do you criticize your nearest eight-year-old for his inability to construct and execute an intricate novel or a symphonic composition? Of course not.
Just look at the long code I originally reformatted. The bug is in the thinking of the coder, and inability to generalize approaches and work at high levels of abstraction. The fault of bad art lies here in the artist, not his paint.
Now, if you would, login to Slashdot and authenticate yourself. I need to have your mail address because your code is broken, and I'd like to discuss this privately in order to spare you public embarrassment.
If you insist upon maintaining your anonymity, then please do not bother to reply.
Re:Decent solution.... (Score:2)
You and yours have an incompatible change between library versions causing mysterious failures in a non-backward compatible fashion. Your toy language gives the most idiotic error message known to man, rendering it utterly indiscernible; this is what makes you want to punch python's lights out. I have never seen a programming language with such horrid error messages. Bug isolation and error recovery would be easier with your eyes closed than reading that embarrassment. A programmer doesn't need this kind of grief from a compiler. Your toy language also doesn't allow you to specify a version requirement the way Perl does with its modules or the way normal Unix shared library stuff does. This is just not something that a serious programmer in a real-world project should put up with. And we don't.
Your code is also inferior in that it does less than Perl's does. Apparenly you've confused the -n flag for some STDIN reading. Read the perlrun(1) manpage next time.
And your sorry script is slower, way slower--glacially slower--than my Perl version, just like so much in Python:
If I wanted to take an order of magnitude performance hit, I'd code in Javascript or something. No thanks, buddy. Get yourself a real programming language.