Bug#243575: X configuration should allow to let out monitor frequencies and allow DDC to get them.
On Fri, Nov 12, 2004 at 04:47:45AM -0800, Daniel Stone wrote:
> 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?
Notice that i checked this a week or two ago when Colin first made me aware of
that patch, and there is no such thing. I could maybe implement it, since i
have access to the pegasos OF sources, and may well do it, but i believe that
it is not as easy as that, and that it may be easier to just leverage the X
sources for checking that info.
I also believe that IBM RS6K boxes don't have this info, but we don't have
anyway a driver for the graphic cards that they ship with so, ...
Also, there is a whole bunch of powerpc hardware that is not even using
openfirmware, but either uboot or prep/ppcbug stuff, or other strange things.
I think those even outnumber the apple boxes, but we don't usually run desktop
linux on them, even if they are quite capable of it.
> > > 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?
Yes, and furthermore, i believe that in some non-standard cases (hear not a
apple branded radeon), it won't even work on apple hardware.
> > > 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'.)
Well, i don't know much about the x86 bioses, but on openfirmware does an
early graphic card initialization, either by using the forth driver of apple
graphic cards, or by emulating the x86 bios on the card as the pegasos OF
does. It is at this level that the DDC bus is probed for EDID data, and that
the apple OF export the edid data to its client-os interface. I think the
pegasos OF could be made to support that also, but as i am not familiar with
the x86 emulation stuff, and in general stay as far as possible from anything
x86 assembly related, i couldn't say more here.
> > 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?
You are quick to call this crap ? How do you think X gets the info ? By
programming the registers of the graphic card to read the DDC bus, and then
reading it. There is nothing stopping the fbdev driver from doing the same
thing. It is only a couple of registers anyway, or at least it is so in the
case of the 3dlabs cards i am familiar with at low levels (permedia 2/3/4,
wildcat vp).
> > 3) Let the X and its drivers do it.
>
> This works, but it's overkill.
Why overkill ? Do you know on a better way to get this info on let's say an
amiga/apus box with permedi2 accelerator ? Or any other random hardware out
there without x86 bios reading support ? Or for that matter a non-forth
enabled pci or agp graphic card plugged in an apple machine ? This card will
not be initialized by the bios, and it is the task of either the fbdev or X to
do the initialization, and thus they are the only ones which capable of
reading the DDC bus.
> > 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.
Well, the 3dlabs cards set up a i2c bus, and then use xf86DoEDID_DDC2 and co
to read the DDC bus and get the EDID. I don't know how the other driver do it,
but i bet that either the ddc or i2c stuff can be used, and if this is not
enough, we can certainly more easily add code for this instead of either
rewriting all of this separatedly, or hoping that whatever non-free firmware
has included the necessary bits of it, and provide us documentation.
> 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.
So ?
> 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?
I think you are wrong, the output format is the one found in the DDC module.
But as this is post-sarge stuff anyway, there is nothing stopping us from
adding the needed code in future versions of X, is it ?
> It's actually the worst solution.
Bah. are you afraid of the coding needed to make it happen ? If you look at
it, it is indeed the solution which makes the most sense, even if coding is
involved.
> > 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.
Err, and you said it is not a standard format just above.
> > 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?'.
Nope, i mean you can get the right monitor info at initial configuration time,
but fail to get it at the next reboot, because the guy switched the computer
on before the monitor, or has the kvm switched to his second box while the
linux box is booting. I have seen both of this happen.
> 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,
Exact.
> 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.
See above for two reason for which i actually had to provide user support and
which may justify this.
> > 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.
Do you see it now ?
> > > > > 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?
When X doesn't find any information about frequencies either from the config
file or from the monitor, X reverts to 640x480 vga timings.
> > > 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.
Why ? X knows a lot more about this than a random user, and many of those
actually have monitors second hand or borrowed, or sitting in the lab since
forever or whatevernot, and not accompanied by any documentation telling the
actual frequencies. In the past month, i have encountered an astounding number
of cases where monitor setup failed, and i had to help the user edit the X
config file. This is unacceptable.
> 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.
And debconf asks us this exact data, and provide some random defaults that joe
random user has no way to know what is exact or not, especially if he lost the
little booklet coming with the monitor, which i bet you at least half our
users will not have under hand when doing the initial installation.
> > > > 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.
Its impractical right now, but it is the only sane way to do this in the long
run in such a way that don't covers only x86 and powerpc apple. Or don't you
remember that debian, even if ubuntu doesn't, officially supports 11
architectures and who knows how many subarchitectures of them ?
> 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.
Well, your diagnosis is wrong. With the advance of debian-installer, the sole
remaining reason why you can't give your mom a debian CD is the X
configuration bit, for all the rest i belive debian is upto the point where a
random user can install debian and bring it to a gnome desktop and start using
it for most usual computer uses. X and maybe ppp analog modem setup, but these
are being phased out fast now.
> > > 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.
And what about sparc, mips, mipsel, m68k, arm, hppa, and all non apple
powerpcs ? alpha and ia64 probably have bios level support, and s390
doesn't have graphic cards anyway. Shame on you for letting those officially
supported debian architectures on the side of the road.
> 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
So, see, the only sane reason is to have separate code doing the edid probing.
And right now, the only place where this has the most chance to be done is in
either the X driver and corresponding DDC code, or in the fbdev layer. Of
these two, i believe X has the most support for graphic hardware, but well,
fbdev could also be modified to handle this.
> 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.
Did i say that ? I advocated a way to detect the edid data which is not
dependent on inexistent or possibly broken bios support, and fall back on what
you always do if not.
> Instead, I chose to walk the autodetection route whereever possible, and
Wherever easily possible given the x86/apple constraints.
> where it was not possible, to pop up a question saying 'hi! what's your
> preferred resolution?'.
And if my prefered solution is to have empty frequency settings, you refuse
it. With a "your frequency range has no ," or something such nonsensical error
essage.
Friendly,
Sven Luther
Reply to: