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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
