On Fri, Nov 12, 2004 at 12:29:53PM +0100, Sven Luther wrote: > On Fri, Nov 12, 2004 at 02:46:10AM -0800, Daniel Stone wrote: > > On Thu, Nov 11, 2004 at 05:15:31PM +0100, Sven Luther wrote: > > > 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 > > Compare it with the number of Apple machines running linux please. It may be > more, but not enough to consider the growing parc of pegasos machines running > linux as insignificant. Or then we don't look at the same definition of the > word insignificant. I don't mean to devalue Pegasos in any way, but my assertion that you can, in the general case, extract EDID data from PowerPC machines was correct. Even so, just try it and if it fails, then that sucks, fall back to asking a question. What's the risk in attempting to open a file in /proc? Do Pegasos machines die if you attempt to cat /proc/openfirmware/DISPLAY0/EDID or something? > > Watson that has been pending for a while. > > Yep, and it will only do the getting of the info from Open Firmware, not real > DDC probing. ... and? Does this mean it's somehow useless for getting EDID data on PowerPC, because it doesn't work for all cases? > > 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. > > As i see it, there are three ways in my opinion of getting the EDID info : > > 1) Let the bios do it, and read it from linux. ... what? Do you mean using a userspace tool like get-edid or ddcprobe to make a VBE call? Are you proposing to have the video BIOS set it up? (Newsflash: it won't.) Are you proposing to read the list of possible video modes via the video BIOS? (This is called 'DDC' via 'VBE'.) > 2) Let the fbdev driver do it, which in the radeonfb case reads the OF tree > and falls back to do its own reading only if it fails or something such. Argh, no, that's crap. How are you going to get the info anyway? > 3) Let the X and its drivers do it. This works, but it's overkill. > I believe that the method 3) is the one with most chance of success on the > wide variety of hardware out there, including non-apple and non-x86 systems, > and probably the best method overall. We need a tool that can get this info > from X though, but i imagine some kind of tool linking with the X drivers > would be the best solution. No, it's not, because there is no defined interface to do this. The X drivers do not have any form of standard name for doing a DDC probe. All of them will have code in their PreInit/Init to check if they're on LVDS/TMDS/DVI/VGA, and call functions to read the panel data or do a DDC probe accordingly, and then fill in values in private structures according to their algorithms. Did I mention that you need a working pScreen and to emulate a whole buttload of functions, like all of int10, the PCI code ... it's just a woefully bad idea. At that point, you're better off just grepping the log and guessing. Did I mention that there's no real standard output format for probed values? It's actually the worst solution. > The configuration will thus work as follows : > > 1) The X configuration launches this tool. ... or a tool which either extracts the EDID from OF or VBE, or (in the worst case), runs X in -probeonly and greps the log files for panel data, which is a *HELL* of a lot simpler to extract, largely because it's almost always (there is only one case where it's not, which is ATI r4xx ATOM BIOSes with LVDS/TMDS, and I've yet to see a laptop featuring an r4xx chipset) on one line, so you can simply do it with egrep and sed. > 2) it gets the mode from the monitor, and tells the user that, asking him if > he want to set them, or if he may change monitor later, wants to let them > blank (defaulting to blank). Letting the blank is safe since X knows how to > detect them, but is not proof to booting with the monitor off or a kvm or > something such. So? In this case, you just say 'dude, I can't probe your monitor, what's your preferred resolution?'. Right now, if dexconf detects (let's say) a huge 21" with massive sync ranges, and you then plug some piddling 12" with tiny sync ranges, you might blow it up. The current scheme doesn't protect against this, because -- wait for it -- you can't. So I wouldn't bother, honestly. X has its own probing handling and it's actually pretty smart, so I don't see the point in trying to outwit it when all you do is prevent sensible hotplugging. > 3) if it fails, inform the user about this, tell them they have a > non-DDC/EDID supported monitor, and follow with the old way of handling > this. > > Does this sound reasonable ? Yes, except I don't see why you should ask question 2, except where you cannot autoprobe the data. > > > > 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 > > Well, the main difference is that the X server is able to use the Ranges > directly, and not doing that interfering you mention, thus you end up in safe > 640x480 vga timings. ... what? > > 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? > > My monitor sections looks like : > > Section "Monitor" > Identifier "Generic Monitor" > Option "DPMS" > EndSection > > There is currently no way i can use the debconf configuration to specify it, > since the sanity checks of the frequency reading stops me from doing that. and > about modelines, my mistake, i meant frequency ranges. I dislike the idea of writing out frequency ranges. If the user desperately needs to specify frequency ranges, why not just let them edit the config file? My mum won't know how to put the frequency ranges in anyway -- if Debconf asked her for her monitor frequency ranges, she'd call me, because she wouldn't know what to do. > > > 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. > > Bah, do you have a way to make VBE work outside the x86 world ? And do you not > think that all this code is already implemented in the X drivers ? So why not > use it ? Loading the X drivers is a dumb idea for reasons I've outlined above. And I don't see what you're getting at. Sure, VBE only works on i386. So, know what means? Use it on i386, and don't use it on !i386. What's the problem with this? Some architectures don't let us autodetect the monitor, so we'll make everyone get their non-existent monitor manuals out to find the frequency ranges? It's obnoxious, and stupid, and it's exactly the reason why I cannot give my mum a Debian CD. > > 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 don't care, i don't have any crappy x86 bios lying around. I'm very disappointed to hear that, but happy to hear that the world's i386 users should be unable to have their resolutions/frequencies autodetected just because your Pegasos does not provide any generic mechanism for doing so. Sven, I've been down the road of X autodetection, and I know what it's like. And, you know what? I'm faced with the situation where detecting resolutions is nigh-on-impossible on amd64 because doing so (well, doing DDC probes via VBE) would involve bringing over a massive, nightmarish, x86 emulation environment. So, according to your resoning, I should have made everyone go find out their monitor sync ranges and the maiden name of the uncle of the monitor's primary designer, or something. Instead, I chose to walk the autodetection route whereever possible, and where it was not possible, to pop up a question saying 'hi! what's your preferred resolution?'. -- Daniel Stone <daniels@debian.org>
Attachment:
signature.asc
Description: Digital signature