On Fri, Nov 12, 2004 at 03:27:28PM +0100, Sven Luther wrote:
> On Fri, Nov 12, 2004 at 04:47:45AM -0800, Daniel Stone wrote:
> > 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.
It is implemented in Apple OpenFirmware. Which is why it works for most
people, and no-one has commented about that patch ...
> 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, ...
... so they're irrelevant to this discussion, yes.
> 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.
They will not be doing desktop installations of Debian, no.
Sven, you keep moving away from the point. The point is desktop
installations of Debian where it can be reasonably expected that we will
at least make some form of half-arsed attempt to probe.
> > ... 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.
OK, so worst-case is that in some tiny percentage of cases (it works on
Apple-branded nVidia hardware, BTW), we don't get EDID data, and we have
to ask the question.
But in the overwhelming majority of cases, we save a question. By doing
a probe.
Again, I ask: are you suggesting that because some small majority of
cases cannot support resolution autodetection (but gracefully fail),
that we must not, under any cases, even bother attempting it?
> > 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.
OK, I see what you mean here. For what it's worth, the way to do a DDC
probe across all x86 video chips (i.e. without vendor-specific routines
that avoid a BIOS call), is to set ax and a couple of other registers,
and call INT 10H, and check what's in those registers after the call
(that's your DDC/EDID data). After that, you restore state and continue
execution.
> > 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).
I suggest you take a wander through radeon_driver.c one day -- it is
absolutely *not* a couple of registers, and you cannot do it simply.
You are suggesting literally tens of thousands of lines of code here,
and that's only for the major framebuffer drivers that people care
about. Surely, if we can't do it for exactly every case, it's not worth
doing?
> > > 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.
No. But equally, do I care? No.
This is about getting it right in most cases, not absolutely every
single case ever, including deducing via ESP whether or not monitors are
lying to us through their EDID data.
If Amiga/APUS with PM2 is really that popular a case that so many people
use it and get forced to answer an extra question, surely patches will
be flooding in, no? I trust that there are many capable developers on
the Amiga/APUS platform, otherwise the hardware will not be supported at
all.
And still, all this effort for obscure platforms will be far easier than
re-implementing the X server or whatever it is you're proposing.
> > 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.
Yes, but the manner in which it is done is not consistent, and cannot be
relied upon.
> > 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 ?
So you're suggesting to load some random blob of binary driver, deduce
the layout of its internal private structures somehow, and then work out
how it stores its data? Doesn't work like that, I'm afraid.
This is all totally opaque to the X server. It calls PreInit, steps
through setup and calls Init, and then somewhere along the way, the
driver will somehow start adding modes. Whether this is from panel data
from the BIOS, DDC, or pure guesswork, we don't know. There is no
consistent way to say 'hey, you, supported resolutions, now'.
Did I mention how much work reimplementing the X server is? You have to
implement the acceleration architecture to limp the driver through
initialisation.
> > 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 ?
This is wrong for the various reasons stated above, but it's not really
worth reiterating.
And you're welcome to patch X for your own needs, and reinvent the
wheel. I reserve my right to dislike the idea.
> > 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.
Do you have any inkling of how much coding is needed? At all? Or what
needs to be implemented just to probe the driver and *not* be 100%
certain that it will fail because you haven't implemented ~10 subsystems
fully?
> > ... 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.
Read carefully what I said.
> > 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.
So? By your logic, we should be begging for new sync values at every
boot, no?
> > 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.
... which is why any future scheme absolutely must, preferably via ESP.
> > 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.
Why does this have to be done at every boot?
> > Yes, except I don't see why you should ask question 2, except where you
> > cannot autoprobe the data.
>
> Do you see it now ?
No.
> > ... 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.
Rubbish.
> > 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.
I know. This is why I'm suggesting that no automatic tool should ever
be writing out HorizSync or VertRefresh. If it's so bad that it cannot
be automatically probed, then the user can edit the config file. By the
time you're digging for your non-existent monitor manual, it's no better
than a Debconf question.
> > 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.
Sven, this is why I am suggesting we never ask this question.
> > 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 ?
Yes, Sven, I remember that. And I know about Pegasos machines. If you
dig into your archives, you'll remember sending me a mail when I was
interested in one, only for me to have to back out because I didn't have
over $au1000 at the time.
I'm proposing a solution that, with minimal amounts of work, will
support 95% of our userbase, bang, that easy. For the other 5%, they
will notice little-to-no improvement, but relative to where you are,
they will not be inconvenienced. You are suggesting quite astounding
amounts of work (which will need to be updated -- do you want to be the
one to track every single ABI change?) in order to support everyone. Oh
wait, except it doesn't support Via owners, because their chips are so
terribly bad that you can't even deduce which displays are connected
except guessing what might be there via a hardcoded table of subsystem
IDs. Thus, by your logic, we should abandon this X solution.
You seem to be violently against improving the lives of 95% of our users
-- while leaving the other 5% NO WORSE OFF than they started -- for no
effort, and instead advocating some random hand-wavey solution (of which
no-one has any idea how it will work) that will involve staggering
amounts of effort, and still won't get any closer that magic hundred per
cent.
> > 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.
'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.'
Most people get in the habit of reading emails before you reply to them.
Not you, it seems. That paragraph you pointed out was me pointing how
the X autoconfiguration is so bad that my mother has no hope of possibly
installing Debian. I don't like it. I'm not sure if I can make it any
more clear.
(For what it's worth, mum also has an analogue modem.)
> > 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.
Shame on me! Woe!
Equally, shame on you for leaving i386 and powerpc/Apple in the relative
s**theap also. Let's imagine this.
Bad Good
---------------------------------------------------------
now: everyone no-one
me: 9 architectures amd64 i386/powerpc
No-one will see any support regress because of this. It's not like you
won't be able to install X on m68k because of my proposal.
I could turn around and say shame on you because I can't hook up a DVI
display to my S/390 and use it, given it doesn't have any graphics
support, but that would be silly. But let me try.
I cannot hook up a DVI to my S/390! Shame on you, you i386 pig!
Clearly the solution is to remove all X support to make everyone equals
in the great tractor collective!
Or something.
> > 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.
... dude, the code is separate. Please go and read the code where the
EDID parsing is separate from the DDC probe (be it via OF or VBE). I
implore you.
We have *REAL* *WORKING* solutions today that do probes via OF or VBE.
I invite you to come back to the table when you have reimplemented the X
server, or magically done it in the fb layer or something (can you
honestly tell me that you have any idea how difficult that is on common
hardware? and no, I don't mean Permedia), since both seem so easy and
you are not afraid of coding.
Obviously the X server is the easiest and best route to take -- I
apologise. I look forward to your patch.
> > 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.
Do you have any idea of how many systems in the wild claim to offer VBE,
but don't? For all your hate of BIOSes, you must be using a system with
no video BIOS or something, since they're all buggy, crap, or simply
non-existent. Who needs something to set up your display for boot,
anyway?
(I'll give you a hint as to the answer to my first question: it's an
integer, non-negative, and it's lower than one.)
> > Instead, I chose to walk the autodetection route whereever possible, and
>
> Wherever easily possible given the x86/apple constraints.
Yes, which is like 95% of the working systems out there.
In terms of code that's out there, we have two solutions:
* VBE/OF EDID reading: works on 95% of the systems
* handwavey X or fbdev or something solution where we just sort of
magically infer the data: 0% of the systems, because it's not done,
and I'm willing to bet you all the beer you can drink in a night it
won't be done to a level where it works, and be maintained that way
for at least twelve months.
> > 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.
... resolution != frequency.
Here is my proposal, in very small words:
probe resolution via vbe/of
if resolution: USE THIS, NO QUESTIONS
if no resolution: ask what resolution they want, write this out, don't
write out horizsync/vertrefresh, ASK ONE QUESTION
Aside from your Pegasos noise (surely if it was a great system with a
working BIOS, it would provide EDID information, and surely if it had a
huge deployment base, this problem would be fixed), what objections are
you raising? Bearing in mind that I:
* do not like the idea of asking about sync ranges
* do not like the idea of writing sync ranges to the X server config
* do not like the idea of asking about sync ranges
* do not like the idea of asking about sync ranges
* do not like the idea of asking about sync ranges
--
Daniel Stone <daniels@debian.org>
Attachment:
signature.asc
Description: Digital signature