On Thu, Nov 11, 2004 at 05:15:31PM +0100, Sven Luther wrote: > On Thu, Nov 11, 2004 at 07:47:17AM -0800, Daniel Stone wrote: > > On Thu, Nov 11, 2004 at 03:24:18PM +0100, Sven Luther wrote: > > > On Thu, Nov 11, 2004 at 05:23:19AM -0800, Daniel Stone wrote: > > > > amd64, i386 and powerpc have working DDC probe support (the former two > > > > > > Nope, powerpc has not, it seems to be only some way of getting the information > > > from the openfirmware probed data, which will work if the graphic card does > > > indeed provide it, which is probably only the case on apple with the apple > > > standard cards. In particular, it fails on my pegasos, and probably also on > > > all IBM RS6k machines. > > > > Well, for the general case, PowerPC has EDID support. There are working > > mechanisms to probe EDID data on machines that support it, which happen > > to comprise the *vast* majority of deployed PowerPC machines. Agreed? > > As we are going to deploy an amount of pegasos machines running debian in the > thousands nextly, i would dispute this *vast* majority claim. Also, i believe > that read-edid is not built for ppc right now, or at least not in sarge. As > debian-installer complains about not being able to install it. 'Thousands' is utterly insignificant compared to the volume of machines Apple makes. There is a patch for read-edid in the BTS from Colin Watson that has been pending for a while. read-edid is a bad idea anyway -- it only deals with detailed timings (and gets that wrong in some cases anyway, IIRC), as opposed to the standard timings table, so I recommend not using it. The concept of DDC and EDID is not limited to one very specific package. > > > He, i have encountered this case at least 5 times this past month. Ranging > > > from cheap monitors, which altough they claim to do DDC/EDID, they only send > > > bogus data to the card, one case was even missing the Ranges fields, or > > > age-old big sun monitors, or even people behind cheap KVM switches, which > > > don't relay the DDC pins. All those i have encountered. > > > > The ranges field is not a problem. KVMs are a problem, and this is a > > Err, how do you detect the allowed frequencies without Ranges entry ? If you desperately need this, you pick an arbitrary frequency and infer the ranges from that, which has the unfortunate side effect of limiting you to a single resolution without configuration changes. In most cases it's fine to just dump it in and let the X server deal with it. > > problem. You can blacklist known bad resolutions (IIRC I have > > blacklisted about four), or compare them against a whitelist of known > > good resolutions. There are many good ways to get around this. > > Yep, and many bad ones probably too. ... as with everything ... > > It won't work exhaustively correctly in every case, but it's really an > > exceptionally sensible default. > > Well, my main grip is that, when the user of the box is installing it, and > wants to let the field empty, he should be allowed to do it, since there are > good chances that he knows what to do. Also defaulting to empty modelines for > flat panels is a sensible default, since most flat panels would have working > DDC support, and giving them default CRT frequency ranges is not a good idea. My point is that the user has no business seeing that question in almost all cases anyway. What do you mean, 'defaulting to empty modelines'? Why should they ever get written out? > > > Now, X clearly knows how to get the DDC info on most plateforms, should it not > > > be easiest to have some kind of X based tool which probes the DDC info, and > > > reports back if it worked. Hell i guess running X in -probeonly, and parsing > > > the XFree86.0.log file should be a cheap way of doing that. > > > > Cheap but crap, yes. > > Do you see a better way which would allow yo do real DDC/EDID probing without > relaying on the bios to do it ? Yes. Almost every video card ever has a separate I-Can't-Believe-It's-Not-VBE interface which allows you to do it without depending on making real-mode BIOS calls. But there's a hell of a lot of code, and it's impractical. Every card ever supports VBE, so let's assume we're stuck with using VBE. Ever considered that X is not the only userspace utility ever which is allowed to touch the video card BIOS? Hell, if you're doing VBE, then it's a single generic routine. I wonder why someone hasn't written a tool to do this[0][1]. [0]: http://http.us.debian.org/debian/pool/main/r/read-edid/ [1]: http://archive.ubuntu.com/ubuntu/pool/main/x/xresprobe/ -- Daniel Stone <daniels@debian.org>
Attachment:
signature.asc
Description: Digital signature