[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ubuntu bulletproof x



Adam Jackson wrote:
On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote:
Adam Jackson wrote:
Yeah, okay, force me to clarify.  Grumble.

There are cases where we can't tell what monitor the user has.  They're
almost completely described by "either the card can't do DDC, or the
cable is broken".  The former is a vanishingly small class of hardware,
voodoo1 basically.  The latter happens depressingly often particularly
with projector setups.

So, to save you the trouble of rereading all of my posts. Can you explicitly confirm this (which it sounds like you did, but not in a way that clearly addressed the point I tried to make half a dozen times last night).

Repeat after me-

"There is *NEVER* a situation, when the monitor fails to provide correct information, due to a broken or absent edid implementation, and which at the same time, sufficient information could be parsed from the .inf that came on the CD with the monitor, to provide the user, a reasonable experience requiring no user interaction beyond putting the cd in the drive". (and at which time, the X driver could not have accomplished the same thing automatically without the .inf)


First, thanks for many of these recent educational responses. Something like cvt I do personally find cool, though clearly it has nothing to do with the type of situation ubuntu-bulletproof-x is targeting.


Absent EDID in the sink device never happens anymore.  It's a
requirement for Vista certification.  I'm fairly sure it was required
for XP cert.  It's a requirement for shipping any DVI sink device.  It
is _mandatory_.

We can fail to get EDID, either because the cable broke the DDC pins, or
timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or
it's a really old monitor, or there's a crap KVM switch in the middle,
or phase of the moon, or whatever.

This sounds like an aweful lot of situations. I suspect my micron apt150t falls into more than one of them (not DVI, not vista certified, probably not xp certified, 'really old', who knows about about i2c timing and/or bios bugs...).

I'll save the details of my s-c-d fun yesterday for a bug report, but suffice it to say that after selecting 'generic 1024x768 lcd panel' and seeing that in xorg.conf, it decided to start up in 1378x768... Not reproducibly though.

My point, if I even have one anymore, is that it sounds like the above (my situation, and what you said), are a multitude of situations where .inf info might come in useful. But you did clarify below...





I have not found ISOs for every OEM CD for every monitor that ever
shipped.  I doubt I ever could.  Therefore the following claim is merely
statistical.  However, on no OEM CD that I've ever found does the
included INF file - or any other resource intended to be parsed by the
machine - provide the same set of information as the EDID block for the
monitor.  It may provide a subset.  The only subset I've ever seen is
sync ranges.

From Richi Plana's posted .inf

"
[1280]
HKR,,MaxResolution,,"1280,1024"
"



I'm not saying I'm happy about that.  I would love to see a
counterexample.  But it's all the empirical evidence I have.

I would truly love to provide a counterexample with my micron ap150t, but as was pointed out elsewhere in this thread, that is one example where the .inf truly does not exist on the face of the earth. But if it did, and had something like the MaxResolution quoted above, that would be a valid counterexample, right?

-dmc

P.S. I honestly don't care enough about this thread to restore my copy of vista on my laptop (haven't had winblowz in my home for >6months) which has a vga-out, to see if windows can do better with that monitor than F7.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]