Bug#243575: X configuration should allow to let out monitor frequencies and allow DDC to get them.
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.
> 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.
> 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.
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.
3) Let the X and its drivers do it.
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.
The configuration will thus work as follows :
1) The X configuration launches this tool.
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.
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 ?
> > > > 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
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.
> 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?
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.
> > > > 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.
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 ?
> 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 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/
Mmm, didn't know about xresprobe, will look at it.
Friendly,
Sven Luther
Reply to: