On Fri, Nov 12, 2004 at 06:39:00PM +0100, Sven Luther wrote:
> 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.
I think it has to be evaluated per-architecture. For i386, it's the
closest imitation of a 'right solution' we have, IMO.
> > 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.
Which involves programming certain registers per-card to get an I2C bus,
usually. And knowing which registers can be tricky ...
> > 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 :
>
> [...]
Yeah, understood. I believe you first have to program the CRTCs,
however, which is a total black art ...
> 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.
Significantly less if we change the published driver API, yah.
Unfortunately you would still need to do Init/PreInit in order to
program the CRTCs and do the necessary setup, which is quite deeply tied
to a ScreenInfoRec, so the change would actually be rather invasive ...
> > 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 ?
If you decided to make all drivers export probed information, then yes,
it would be significantly smaller, but we're still talking about a very
invasive patch. Bear in mind you have to get the PCI bus IDs, et al ...
> > 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.
Right, however setting the card up without a ScreenInfoRec or any of
that sort of thing is still rather quite difficult, and it's politically
difficult to change the (unofficial but still rather concrete) driver
API.
> > 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.
Oh, reading it from VBE is a disaster. Really, I dislike it. But I
just believe that it's the only way to do it with any vague semblance of
portability.
> > 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.
Unfortunately, doing the init is more difficult than just poking bits
into random registers; check (for a good example) the radeon driver
again (grep for 'RADEONInit.*Registers'; while we don't need most of it,
it's just an example of how complicated general card setup is).
> > 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.
Personally I favour the long-term solution of moving all of this sort of
stuff out into a generic layer that both X implementations,
framebuffers, DRI, that sort of thing, and beating the information out
of that via a standard information.
But yeah, when you talk about extending this past 3dlabs and into ATI,
nVidia (no-one else but them can change their driver -- take a quick
stroll through nv_driver if you don't believe me), Intel, et al, is
going to be quite difficult, especially if you need to negotiate setup
without most of the core infrastructure (a ScreenRec, XAA, whatever)
present.
> > 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.
Sorry, I thought you were talking about having your own server
implementation which dlopen()ed the modules.
> > 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.
Yes, I misunderstood.
> > 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.
Yes; unfortunately I cannot put any code into the X tree at all, more
than any random person can (via the BTS), expect by putting it in
upstream and hoping it will eventually creep into Debian.
> > 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.
Unfortunately you can't legislate against stupidity ...
(Talking about the last part of your paragraph, not the first.)
> > Read carefully what I said.
>
> You said that the edid information is not standard. The only real data we need
> is the Ranges one.
Last I checked, none of the markers printed around EDID data were
correct, and it's also difficult to find out what they're referring to
(internal laptop panel, external VGA, whatever).
> > 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.
I didn't know this; when did that happen?
> > ... which is why any future scheme absolutely must, preferably via ESP.
>
> Sorry, i don't know ESP, what is it ?
Extra Sensory Perception -- basically, knowing things that other people
think.
> > 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.
Mmm. I think the likelihood of it having averse effects is actually
lower than the possibility of mum accidentally mixing up the vertical
refresh/horizontal sync ranges, or mistyping them, or something.
> > Rubbish.
>
> I can forward to you all those reports stating "why are my icons so big" if
> you want :). I have load of them.
Er, unless something's changed since I last wandered this code, this
will only happen if 640x480 is specified in the config file, which it
shouldn't be. There was no 'oh well, let's try 640' code in X, last I
saw.
> > 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.
Your choice.
> > 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.
(Nor can I.)
> 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.
... yes.
> 2) change the driver from ati to radeon since X doesn't know about the
> second head of my radeon 9200 SE.
Yes, the ati driver apparently needs patching for these cases still; it
is crack and I personally prefer atimisc/r128/radeon directly, but there
you go.
> 3) add more reasonable reasonable resolutions than just 800x600 and 640x480.
Yes.
> 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.
Well, you can't win 'em all. :)
> 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.
Our experience is that it has been immensely difficult, however -- like
people who live in Sweden, speak Finnish, and have a US keyboard, or
something. Covering all the possibilities is really, really, really,
really, really, really, insanely hard, and honestly about twenty times
harder than I even really considered.
> > 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 ?
... never ask the question -- if we can avoid it.
> > 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 ?
This seemed to be the gist of your email, but I'll accept your point
that it isn't.
> > -- 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
> ...
Heh. Although, as an X developer and maintainer, I would *love* to have
those logs so we can go patch around specific cases, if need be (I mean,
there's nothing we can do about crackful monitors, or KVMs, or whatever,
but panel detection bugs and the like are fixable).
> > '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.
Seems we're both talking past each other.
> 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.
OK. I'm suggesting that we attempt to probe via DDC, and if we ask,
don't probe for frequency lines, because:
a) maybe X can work out and we have a busted VBE BIOS or something
(I've not seen it but it could happen), or
b) we can work out, based on which resolution they've asked for, a
reasonable HorizSync/VertRefresh line.
> > 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.
Not entirely, actually. One of the more interesting things about the
X -configure stuff is that it shells out to a policy engine IIRC, which
means that the policy engine could just call back into Debconf or
anything; I was thinking about this tonight.
If this is possible, I'll be experimenting with it and seeing if I can't
get rid of my hand-hacked DDC code which is a mixture of read-edid and
ddcprobe (plus the egrep/sed mixture for inferring panel resolutions via
X -probeonly).
> > (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.
Not in Bendigo (regional Victoria), there isn't. Well, there's aDSL,
but last I looked, 256/64 was $au250 a month base, plus some
*exhorbitant* cost per megabyte. At that price, two-wave satellite is a
viable equivalent.
I only moved off a modem on to DSL in October (Australia has
infrastructural issues with pair-gain lines and DSL which are only just
starting to be resolved, so while the prices are good in the city, some
houses simply cannot get it).
> > 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 ?
read-edid isn't actually a good tool to use for this, because it only
reads detailed timings, instead of standard timing tables.
> > 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've already implemented it. :)
> > 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.
Well, it builds, but there are no S/390 graphics cards ...
> > ... 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 ?
No, but they are implemented in .debs ...
> > 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.
Unfortunately, your access to the Debian XFree86 SVN repository is as
good as mine; Branden decided to remove me long ago.
> > 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 ?
You have a guarantee that it will be the same, because I was explicitly
removed from the XSF long ago.
> > 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 ?
As I keep saying, it is. :)
> > ... 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.
Unfortunately I won't be home near a desktop for another month and a
half (and I have been away for another two months not long ago at all),
so reinstalling isn't really viable for me at the moment.
> > 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.
You can infer the H/V ranges from the resolution quite easily.
> > 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.
I don't know of any flat panels out there (beyond 486 laptops) which do
not support either DDC or reading the timings from a BIOS table via the
driver.
> 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.
Er, right, but if we're down to the case where we can absolutely not
find ranges, we can ask about the resolution and derive the ranges from
there.
--
Daniel Stone <daniels@debian.org>
Attachment:
signature.asc
Description: Digital signature