Bug#243575: X configuration should allow to let out monitor frequencies and allow DDC to get them.
Okk, let's try to focus a bit again. Err, finally it is not as short as i
wanted, sorry.
On Fri, Nov 12, 2004 at 07:50:31AM -0800, Daniel Stone wrote:
> 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?
What i am asking is that :
1) you don't consider the VBE/BIOS/whatever solution the right one and stop
looking at other stuff. Debian still support all the other arches, and they
deserve to get an easy solution too. Calling any non VBE/Bios solution crap,
well, it is not going to help improve the situation.
> 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.
Sure, but again, we are talking about the non-x86 non-apple call.
> > > 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.
Well, as far as the 3dlabs graphic cards are concerned, it is not only two
register, but exactly two bits out of those registers. Or 4 maybe, one for
sending, one for receiving, and a timing register for each one if i remember
well. Now the radeon_driver.c code is probably full of stuff to first look at
the VBE code, then at the apple OF one, and then only fall back to reading per
DDC, and finally some fallback for the known case of apple laptop panels which
don't have DDC support. Still, the act of actually speaking to the ddc bus is
probably using only a few registers and looking at the actual code in
radeon_driver.c code at line 812, i see that seems to be indeed the case. In
fact there are some stuff to initialize the card, but basically, what happens
is that you set following i2c bus registers :
info->pI2CBus->I2CPutBits = RADEONI2CPutBits;
info->pI2CBus->I2CGetBits = RADEONI2CGetBits;
And the two Put/Get Bits do not much more :
get :
val = INREG(info->DDCReg);
*Clock = (val & RADEON_GPIO_Y_1) != 0;
*data = (val & RADEON_GPIO_Y_0) != 0;
put :
val = INREG(info->DDCReg) & (CARD32)~(RADEON_GPIO_EN_0 | RADEON_GPIO_EN_1);
val |= (Clock ? 0:RADEON_GPIO_EN_1);
val |= (data ? 0:RADEON_GPIO_EN_0);
OUTREG(info->DDCReg, val);
/* read back to improve reliability on some cards. */
val = INREG(info->DDCReg);
And this is rather similar to what i know of the 3dlabs chips, and i guess a
whole bunch of other cards for which i didn't write the X driver and thus am
not familiar with. All the cards that do DDC over i2c, which include all the
modern cards, have such a setup. So, would it be so difficult to have in a
next version of X, the driver officially export this capacity, in a way that
you can access it without using a screeninforec, and write a small tool making
use of it ? I bet you that this can be achieved with significantly less than
tens of thousands of lines of code.
> 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?
So, tell me again, am i missing something, or do you reconsider in light of
the above ?
> > > > 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.
Just exposing a few functionality which most driver already implements, and
some glue code to make call of it outside of X. Really not all that much code
or time would be involved in this, and i may not be a Debian X strike force
guru, but i did do driver development for XFree86, and am not totally ignorant
of the code base.
> > > 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.
Well, while the fact of reading it from VBE is ? And still i dispute the fact
that the current code is all that dissimilar.
> > > 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.
No, we just need to officially make the info->pI2CBus structure visible from
outside the driver have some hooks for doing preinit for hardware that needs
it (like the radeon seems to), and then have one hook to actually get the
perfectly standard edid data out of xf86MonPtr structure, or whatever is used.
> 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'.
Not yet, but my experience from writing X drivers for the 3dlabs cards shows
me that this is not all so opaque, and much easier than you believe. Hell it
is probably easier than reading the VBE provided data in the first place. It
does need modification of the X driver code to add a few user visible function
though, and some code to duplicate the detection, module loading and actual
calling of those functions. Not something we can do for sarge, agreed, but
definitively something that could be added to etch, especially as we are going
to drop XFree86 for whatever other solution.
Maybe even an xfree86 -probe-edid kind of solution would be even easier.
> Did I mention how much work reimplementing the X server is? You have to
> implement the acceleration architecture to limp the driver through
> initialisation.
Reimplementing ? All is already there, we just have to use it. The crux of
this proposal is exactly to not duplicate and reimplement code.
> > > 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.
That you believe it would need a whole reimplementation of the X server, as
well as tens of thousands of lines of code. Well, i believe you are wrong on
that point.
> And you're welcome to patch X for your own needs, and reinvent the
> wheel. I reserve my right to dislike the idea.
Well, the last time i submitted a (trivial) patch to the debian X strike
force, well, it is still sitting in the BTS, will never be applied, and is
almost two days old, so, i will think twice before doing any X work and
loosing time that will never even be considered, due to pure lazyness of the X
maintainers. And you know which code i speak about, or you should.
> > > 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?
Sure, i am a XFree86 developer after all, did write X drivers which i sent
upstream, and have some knowledge of the whole tree. Hell i even have commit
right to the XFree86 CVS, for all the good it does me now that they commited
suicide and jumped head first in the path to obsolency.
> > > ... 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.
You said that the edid information is not standard. The only real data we need
is the Ranges one.
> > > 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?
No, but we should let the user make the choice, at least in medium priority.
Hell, a standard debian/sarge install don't even asks about screen resolution
and defaults to 800x600. Speak of user friendliness.
> > > 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.
Sorry, i don't know ESP, what is it ?
> > > 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?
No. It has to be done the first time, but the user warned, and be able to
chose if he wants to keep empty frequency entries or want to set a fixed
value.
> > > 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.
Well, i thought like you at first, and that we should just remove the
frequency lines at all. I have reconsidered this on my experience of
deployement of all those pegasos boxes, either in an industrial setup or from
joe random user with old monitor setup.
> > > ... 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 can forward to you all those reports stating "why are my icons so big" if
you want :). I have load of them.
> > > 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
No. Then the user can enter the right value in the debconf question.
> time you're digging for your non-existent monitor manual, it's no better
> than a Debconf question.
All i am really asking for the time being, is to be able to enter empty values
at that debconf question, and leave these fields out of the config file. This
i cannot do right now.
Also note that i right now need to edit the config file in 4 locations to make
it work :
1) removing the HorizSync and VertRefresh lines.
2) change the driver from ati to radeon since X doesn't know about the
second head of my radeon 9200 SE.
3) add more reasonable reasonable resolutions than just 800x600 and 640x480.
4) set my keyboard values. This is better since localization-config came
about, since the normal debconf still continued equating powerpc with
macintosh, which is obviously false. Still as i am using a french locale and
a us keyboard, this is still not working.
It is a shame though that we have to resort to localization-config for doing a
sensible thing with keyboards though, and not have X debconf's configuration
do something more sensible, like i proposed many month ago.
> > > 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.
Well, i don't understand this. You said automatic detection is not possible
for a non-negligible set of debian supported machines, and then you want ot
never ask the question. How are you going to solve this ?
> > > 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
Yeah, but i didn't say we need to do this immediately, but it is assuredly
possible in the etch timeframe. And less work than you fear.
> 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.
Point taken.
> You seem to be violently against improving the lives of 95% of our users
Did i say that ? please tell me exactly where i said you should not implement
whatever stuff using read-edid, or whatever other solution ?
> -- 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.
So, asking people with problem with X to send us their /var/log/XFree86.0.log
file in order to extract the edid data and ask them to enter these values in
the debcong question is better ? Speak about the progress of the computer age
...
> > > 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.'
What are you smoking, i never said that.
I said that the right solution would be to have some X support for detecting
EDID data, but this is long term, failing that you do as we do, maybe have
some existing read-edid support for providing firmware detected data, and
failing that, allowing the user to not set any frequency line for his monitor,
which is _NOT_ actually possible.
> 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.
Ok, this will be the major challenge for etch, this and some upstream
development to make this aspects easy. I know that David Dawes and other were
working on some configuration-less X server, but since they sabotaged
themselves that code is lost to us.
> (For what it's worth, mum also has an analogue modem.)
Yep. I also do support for pegasos users which have them, still you cannot
deny that those are being phased out fast, with already words of 15Mb/s ADSL
out there.
> > > 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.
Well, did i say this ? I didn't. It was all along my impression that x86
debconf was doing sensible things, and that powerpc/apple would also if the
patched read-edid is uploaded, which nobody seems to be in any hurry of doing.
At least it seemed so because on powerpc/pegasos, a clean debian-installer
run, and i do one such almost daily, tells me that it failed to install
read-edid. I wonder what good is installing this package if it is not used for
X configuration ?
> 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.
Well, what are you waiting for implementing it ? Assuredly not me claiming
that in the long run a X based solution would be best, and please allow me to
set empty monitor frequency values in the X debconf questions.
> 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.
Ah, you can, i never thought that, since all echos of s/390 i heard, X was not
fully building on it or something such.
> 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.
Sure, but not implemented in debian, right ?
> 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.
Please apply the patch from me to build the X SDK kit first, it has been
waiting in the BTS for near to two years now.
> Obviously the X server is the easiest and best route to take -- I
> apologise. I look forward to your patch.
Well, i heard you say something similar two years ago, and my previous patch
is still roting in the BTS. So, i have no guarantee that this will not be the
same this time ?
> > > 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
So, why is it not implemented ? I heard of read-edid first a year or two ago ?
> * 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.
What do i care about resolution. It is the monitor frequencies that are
important, since you can set all the resolutions you want in the debconf
questions, if the monitor and the random values set by debconf don't agree,
you get either a blank screen or a 640x480 fallback. Try it some time.
> 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
I don't understand how this is. Currently the default install asks for
horizsync/vertrefresh, but don't ask for resolution settings. The important
thing is the horizsync/vertrefresh values, which need to be probed, and not
the resolution, where there is no way you can do it without asking the user,
at least for confirmation.
> Aside from your Pegasos noise (surely if it was a great system with a
What has that to do with anything. I bet you that the problem is the same on
any machine i will use, and from what you say it will even be such on x86
hardware right now.
> 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
Well, i think the main objection to this is that just plain not writing the
horizsync/vertrefresh, altough fine, and what was my plan 6 month ago too, is
_NOT_ error proof, and if X fails to read the edid data, it will automatically
fallback to 640x480 whcih the flat panels do not support right now. This is my
experience, and i have had numerous cases of problems with it. Well less than
100, but most assuredly more than 10.
You can give X all the resolution it wants, if it is not conformant to the
frequency info, it will only be discarded at boot time.
Friendly,
Sven Luther
Reply to: