From rick@linuxmafia.com Wed Feb 26 00:24:15 2003 Date: Wed, 26 Feb 2003 00:24:15 -0800 From: Rick Moen To: Alexander Mitelman Subject: Re: next installfest? Quoting Alexander Mitelman: > I e-mailed back and forth with one of the Red Hat developers who works > on the Anaconda auto-config, and he asked me to post the issues with > the Dell display on their bugzilla: It's a fairly new monitor and is > evidently not in the installer configs database in RH 8, yet. But he > didn't directly show me how to do the config properly. I can't speak to how anaconda auto-config solves these problems, but I know that one of the big advances in the version 4.x XFree86 software itself is that it automatically uses the VESA BIOS Extensions/Display Data Channel (VBE/DDC) standards to query monitors for their technical characteristics. Pretty much all monitors of the last decade have given useful responses to DDC queries, so in my experience you can almost always generate a good XF86Config-4 files like this: # XFree86 -configure That command generates a prototype XF86Config-4 file in root's home directory (and gives you brief instructions on how to test it), and in my experience it comes out nearly perfect. I've observed a couple of gotchas, by studying the results of that command and reading the /var/log/XFree86* logfiles resulting from attempting to use the prototype file: 1. Sometimes the colour depth, Modes, and DefaultDepth specs down in the "Screen" section near the bottom just aren't ideal. So, you edit that part manually, if need be. 2. The X server sometimes can't figure out the mouse protocol, figuratively shrugs, and puts "auto" for the protocol, by default. So, you often have to hand-edit that, too -- and I figure it's best to set /dev/mouse by hand in advance, too. In olden days, I was really good at XFree86 v. 3.x configuration. It's sort of a lost art. XFree86 v. 4.x makes that skill nearly obsolete: At a minimum, all the stuff we used to have to do with selecting the correct X server binary, trimming modelines, and specifying monitor capabilities, _is_ obsolete. The other thing you have to watch out for is the fact that some video chipsets require particular drivers in the running kernel. -- Cheers, Founding member of the Hyphenation Society, a grassroots-based, Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed, rick@linuxmafia.com modern-American-English-usage-improvement association. [Sasha was still trying to configure X11 for a particular problematic Dell LCD monitor, and found this Web page useful, as it suggests hand-adding a specific modeline to the XF86Config-4 "Monitor" section: http://marc.theaimsgroup.com/?l=xfree86&m=104317890428348&w=2 ] To: Rick Moen Subject: Re: next installfest? Date: Wed, 26 Feb 2003 19:54:13 -0800 From: Alexander Mitelman Rick Moen writes: > I appreciate the offer. If there's any insights you arrive at that > might be transferrable to other cases, I'm interested. So far, I've > mostly gotten along fine in the 4.x series through a few manual tweaks > and a bit of basic debugging logic, but a few more arrows in my quiver > couldn't hurt. Hey Rick, I hacked some more and got it working. A Google search on "xfree86 modelines" turned up , which has a useful guide. I used the calculator link at the bottom to generate modelines for 1280x1024, 1152x864, 1024x768, 800x600, and 640x480 (these were the resolutions I got from the WinXP control panel, cross-checked against the specifications on the Dell page to make sure I wasn't doing anything insane). I entered them by hand into the "Monitor" section in /etc/X11/XF86Config, restarted X, and voila. it even boots into gdm without a problem. The issue seems to be that none of the config tools properly identify the modelines for this monitor, although the /var/log/XFree86* output seems to suggest that at least some of the modeline info is in fact correctly picked up by the hardware. I suspect this may be because the monitor is very new -- from the log, the hardware reports a build date of December 2002. I'm going to send this info to the Red Hat Anaconda guy and the appropriate person at xfree86.org, but for now it appears that using this monitor with RH 8 is probably beyond the reach of a true newbie: At the risk of sounding a bit arrogant, I have a hard time imagining my friend (whose computer this is) knowing where to look for modeline info, let alone hacking XF86Config by hand. On the other hand, updating the database of known monitors shouldn't be too hard before the next Red Hat release. Anyway, thanks for all your help! (I'll leave you alone now... :) ) cheers, sasha m. Date: Wed, 26 Feb 2003 23:03:57 -0800 From: Rick Moen To: Alexander Mitelman Subject: Re: next installfest? Your results were surprising, so I decided to do a little research, in hopes of making this square with what I thought I knew about XFree86 4.x and VESA's VBE/DDC (VESA Bios Extension/Display Data Channel) standards. It turns out that the acronym I was reaching for is EDID (Extended Display Identification Data). EDID is a binary format that recently-manufactured monitors use to encode display timings, when queried over the DDC (Display Data Channel) by the video chipset. Which the video chipset can be instructed to do by, for example, the XFree86 v. 4.x display engine. To quote from the standards definition: VESA has developed the EDID data format as a compact method to specify the capabilities of various types of monitors as well as integrated displays. This standard defines data formats to carry configuration information to allow optimum use of displays. It is anticipated that EDID format data will be transported by a variety of communication protocols. There's a Linux utility called "read-edid", specifically to query this information. The developer site for that utility says "XFree86 4 (but not version 3) integrates this functionality on some video cards, so read-edid isn't needed then." In other words, XFree86 4 incorporates something rather like read-edid, but it's not the same codebase. It goes on to say that, after running read-edid (as the root user): "If everything ran smoothly, a XF86Config style monitor description should have been printed to stdout. You could put it in your XF86Config or use the information to generate more modelines (see XF86Config(5) and the XFree86-Video-Timings-HOWTO)." See: http://web.onetel.net.uk/~elephant/john/programs/linux/read-edid/ (includes some additional tips on monitor scrutiny, and how to use the modelines the utility generates). On the Debian distribution, read-edid is in a package of its own (as is the mdetect mouse-detection utility), and "If the mdetect and read-edid packages are present, the debconf scripts in [the XFree86 4.x server] package will use them to attempt automatic configuration of your mouse and monitor." Anyhow, the above is the basis of my rather vague suggestion, earlier, that XFree86 4.x's monitor-probing cababilities _should_ make the entire modeline-editing magic that we used in 3.x days obsolete. It's possible that Red Hat 8.0 omits this functionality from its XFree86 4.x server package, or that it simply doesn't work with the particular Dell monitor, e.g., because the monitor responds in the thus-far poorly understood EDID v. 1.3 format, or that the video chipset doesn't do the VBE/DDC extension. Anyhow, the above may add to your understanding of the situation (it did mine), and give you one additional relevant tool in the form of read-edid. -- Cheers, Founding member of the Hyphenation Society, a grassroots-based, Rick Moen not-for-profit, locally-owned-and-operated, cooperatively-managed, rick@linuxmafia.com modern-American-English-usage-improvement association. To: Rick Moen Subject: Re: next installfest? Date: Thu, 27 Feb 2003 12:29:31 -0800 From: Alexander Mitelman Thanks for the thorough explanation. I ran read-edid on the new machine and it does spit out a modeline -- not exactly matching any of the ones I put in by hand, but the numbers look sensible. It certainly *does* read stuff from the monitor (which is in EDID version 1, revision 3 format), at any rate. So I guess the conclusion is that either Red Hat's installer, or the config utility in XF86, or both, do not handle the information from this particular monitor correctly, at least not without some help. Definitely one to keep "in the quiver," as you said -- I am a big fan of keeping notes on stuff like this when I learn it, because i hate tripping over the same stuff twice. Looks like something Red Hat and the XFree86 guys would probably want to know about. p.s. on the read-edid page it notes an option called "noDDC" -- i had to invoke the RH 8.0 installer with "linux resolution=1024x768 skipddc" to ket it to work correctly. Kind regards, sasha m.