Slashdot Mirror
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?
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?
Corel Linux's installer seems to probe your monitor the same way that Windows does. I was quite impressed when I was beta testing it and went to /etc/devices, the exact modelines for my monitor were right there, one for each of it's four favorite modes. Too bad I didn't save that when I switched back, I could have this baby running at 85Hz!
Wow! I had no idea that so many people have problems getting X to work. I always thought that I would have more trouble than most with my new and unsupported video card! I use an ATl All-inWonder 128 thingy, and I can get 1280x1024 using xf86config (and I did it wilest being a newbie)! I guess that I'm lucky to have a Trinitron... I'm not trying to brag, but... I didn't know that getting X to work was so hard!
As always, things like this swing both ways. I don't complain too much about the X configuration and the modelines. In fact, my biggest problem with X has traditionally been to get the keyboard correctly installed and not the monitor. I like X and I like modelines, they make my monitor go 110Hz instead of 90Hz which the Windows drivers refuse to cross.
I've got a Toshiba Portege 3010. It has a port expander that allows me to plug in a second monitor. There's a button labeled 'Fn' that pressed with 'F5' switches the display to either monitor or both.
I was wondering if there is a way to use this to create a dual-headed display?
http://www.inria.fr/cgi-bin/nph-col as-modelines
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
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
I have only set up X under Redhat, and so with the advantage of xf86config.
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!!
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
Not a troll. I had no idea people had problems getting a monitor to work either. In my case, I found an easy was to find information by scanning dejanews for each monitor I set up. Setting up the maximum resolution and refresh rate is easy if you know how to use a search engine.
...oh, there's a little hack in that search query on deja to rid most of the advertising crap.
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 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.
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.
Nope. It's the same screen (same video card, same video memory, etc). No way to split it so that you get different things to the monitor and LCD. You'd need a second video card for that.
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.
--The knowledge that you are an idiot, is what distinguishes you from one.
In my experience with the various distros, I noticed that Corel gave me a refresh rate of 60hz with the 1024x768x16bit mode it chose for me.
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.
Illegitimi non carborundum
1. Use xf86config
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.
Sax took the pain out of modelines and getting the syncs for different modes right. If you know your basic monitor data - Hsync range, Vsync range, you can in expert mode enter it and configure your monitor if it's not in the database (did so with LCD). Then you can finetune the individual modes with a graphics interface.
##
## -----> 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)
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.
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.
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
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.
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
San Francisco values: compassion, tolerance, respect, intelligence
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
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?".http://pegasus.rutgers.edu/~elflord/unix/modeline/
If anyone out there is using a NEC MultiSync 5d, and has gotten it to go over 1152x864 please tell me how! I did it in windows, but in X I can't get it to work. I don't have the manual, and a search of the net was pretty much fruitless. I found lots of stuff about the other Nec MultiSync 5x models, but nothing about the 5d.
always worked well, and involved a lot less reentering of the wheel than xf86config. YMMV.
Lacking <sarcasm> tags,
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.
:) and maybe Jenny Linux Girl tried it before, and submitted the modeline(s), then Joe Average has it easy. What does anyone else think?
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
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.
--
Fuck the system? Nah, you might catch something.
that XFree86 got this reputation due to shortcomings in the "easy" configuration programs, such as XF86Setup, XConfigurator.
.inf file for the info we need, does anybody here know what'd be involved in doing that?
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"
This is just like television, only you can see much further.
Awhile back on slashdot there was mention of an XFree86 Modeline Database on the web... the URL is http://www.netmaster.ca/fvlug/monitor/. Give it your montior's name and it spits out Modelines. You can also submit your monitor's info for others.
---
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.Different automated tools that exist to create or select modelines work with different degrees of succsess. However, what one really needs as a good personal backup solution in the case these tools fail is a private database of typically used modes. Monitors file from doc directory of XFree installation is a good place to start. You can copy all modes people have created, indentify individual ones and sort them by resolution and dotclock. (For ignorant, dotclock is the first numeric value in the modeline definition).
.... etc (the same for other resolutions). Once you have such private database built, I doubt you will ever find a monitor that does not work.
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.
Unix SysAdmin and Programmer
XFree comes with a number of "stock" modelines included in the sample configuration files. They go up to 1280x1024. By combining these modelines with the maximum horizontal and vertical frequencies of your monitor, X can pick the best modeline possible for monitors up to 1280x1024.
.INF file, you are generally out of luck with MS-Windows. Not so with XFree. On the gripping hand, many OEMs provide .INF files, while few provide XFree mode lines.
.INF file from Samsung's website, and fed it into MS-Windows. To set it up under XFree, I cut and pasted the modeline from their website. In both cases, I was up and running in seconds.
.INF, taking advantage of the larger installed base of MS-Windows. Other people have posted more information on such a program elsewhere in this discussion. (I see no need to invent a new specification format just for XFree; MS's files work fine for this; why reinvent the wheel?)
.INF files. It won't matter how easy it could be to setup X unless we actually make it so.
;-)
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.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
So you don't mind spending a little extra time to max out the performance on your system, but if you have to spend 10 extra minutes to get a user's refresh rate up to something where they won't be able to count the scan lines going down the screen, that's a problem?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
1. Write down that FCC id from the back of the monitor.
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.
I have around ten years of PC experience, including tweaking, optimizing, configuring HW and SW, programming in various languages, and countless DOS, Windows & Mac reinstalls. I am not a moron. I read manuals, I do research on the Web, and if I don't know how to do something I know where to learn. But I have never had as much frustration as when I tried to get X running on my system. The card is an ATI Rage IIC. Yes, I RTFM. Yes, I had all the numbers on my monitor. Yes, I read esr's FAQ. Guess what? None of it helped. No matter what I did, at best I always got a screen that was clear on the left side and distorted on the right. I upgraded my XFree86 installation. I switched between three different distributions (Debian, Red Hat, Mandrake). I tinkered with XF86Config until I wanted to shoot myself. Nothing worked. I banged my head against it for a month. Then I asked about it at comp.windows.x to see if anyone else had had this problem. I got ONE response, from somebody who had the same thing happen to him and was hoping I would get an answer. I never got any help at all. I finally swapped in a crappy old video card and got it working, but later took it out so I could concentrate on learning the command-line interface. I'll buy a different video card later, when I have more money and when I've learned my way around the system the hard way. So, I get very frustrated when I see people complain that if you can't get it working you must be clueless. I can easily imagine less sophisticated users being completely turned off to Linux by: 1) the relative difficulty of using it; 2) the difficulty in some cases of getting it working at all; and 3) the contemptuous attitude of those who have figured it out and therefore think they're hot shit. Every single one of you was once a newbie. Please try to remember that. p.s. Advice and constructive criticism are welcome. Flames will be cheerfully deleted.
"We only want a quiet place to finish working while God eats our brains."--Bruce Sterling
For instance, try to figure out how to change your monitor resolution in less than an hour, starting from "resolution" or "monitor".
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
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. 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
Editor, A1-AAA AmeriCaptions
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.
Yes, quite, I did a little calculation at the time and this was the highest res I could get with the card I had at the time - I didn't even know that Suns (& as you State Macs have this res available too in Mac OS 8.5 & 8.6).
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.
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?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
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.
I would appreciate it if the author of this code would publish his mail address so I can contact him. His code aborts with fatal exceptions, and I'd like to know why.
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.
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.