Created attachment 20776 [details] [review]
Patch correcting reported bug

Tested this just now, running at 1280x1024 ( native resolution for the ViewSonic VA930M ) 

The driver now continues on and attempts the alternate enumeration routines.

Created attachment 20777 [details]
Xorg log file -- post patching -- demonstrating detection of correct mode.

Created attachment 20778 [details]
Ye Olde xorg.conf

Comment #1, of course, should read ... 
"Looking through src/i830_crt.c"

But you knew that already.

Thanks the patch. I'm reopening as I guess you want someone to review/commit the patch before this issue closed.

I think Keith has done a CRT detect improvement in master, but not sure if it hits 2.5.0. Could you test current git master? 

Any details of your 945G hardware? I've never seen hotplug detect failure on such machine.

Unfortunately, my build environment won't work against Git.  I didn't have too much time for this, so I just grabbed Fedora's xf86-drv-intel source package, applied my patch, and rebuilt the rpm package -- installed and Voila! -- therefore I can't be the one to test against the current repository sources.

Re:  Hardware.  I *think* the complication is the 10 year old KVM switch between the VGA cable of the ViewSonic VA930m and the chipset on the motherboard.

oh, Mike, you have to tell the KVM story in the first place. I think your patch may work in some place, but I'm not quite sure if it could break anything, as that involves more testing. And we'd like to eliminate pipe stealing to reduce screen flicker in detect.

I'm coming into this without a lot of backstory, so please bear with me here, and thank you for your attention and patience -- I'm only here because on Tuesday night I got a new motherboard with a 945G chipset, plugged it in, and got told that VGA was Disconnected.

I originally tried to google my way out of this issue -- and there are plenty of links to people having issues with EDID failing and, with a VGA monitor connected, and being told that VGA is disconnected.

There was a lot of "If you have this card ( from another vendor ) use these options to disable EDID detection".  I wonder how many people just ran out grabbed another card (from another vendor ) to replace their onboard chipset, because the subroutine is broken, and they couldn't disable the EDID detection?

A question:

Is the goal of this subroutine ( i830_crt_detect ) to detect if there's a CRT hooked up using it's best efforts -- regardless of chipset?  Or does it try to only detect SOME CRTs depending on chipset's EDID capability or lack thereof?

Which leads us to another thing, the handling is inconsistent between the detect_hotplug call wrapped in  "if (IS_I945G(pI830) || ..." and the detect_ddc call wrapped in "i830GetLoadDetectPipe".

First, the "if(IS_I945G(pI830) || ..." falls through to the next block if it fails, but the "i830GetLoadDetectPipe" exits with a 'StatusUnknown".

Then the detect_hotplug call exits regardless of result, while the detect ddc call falls through to the detect_load block.

It's broken already when it reports "VGA DISCONNECTED" and dies -- while there's a VGA monitor connected.

I think the proper behaviour is to give it your best shot with EDID, and if that doesn't work, fall through and give it your best shot with DDC, and if that doesn't work, fall through and give it your best shot with Load.

OR, the subroutine should report "StatusUnknown" to the caller and hope it does the right thing with the information.  Because there's a monitor there.  It works.   It's NOT DISCONNECTED.  To report that it's disconnected is wrong, by definition.

Now, absent a configuration option to toggle completely ignoring the EDID detection, I don't see an easier way to get consistent, expected behavior.

Which raises the question for me ( remember, I'm a newbie here ) Is the expected behavior defined anywhere?

Because, as it stands, the driver doesn't try to detect if there's a CRT hooked up as best it can.  It tries EDID for some chipsets, DCC for others and returns "StatusDisconnected" when it's really "StatusUnknown".  -- and that's just wrong.  Unless I'm missing something...

If not use KVM, does your 945G's CRT can detect right?

The original monitor cable alone can't reach the computer, because of the way the room is laid out.  The KVM serves also as an extension.  Remember, this is my home computer, not at work in a lab or anything.  

I guess if I wanted to do the heavy-lifting, I *could* try it, but it's not worth the hassle -- given that I've already found the bug.

And it seems I had earlier answered the question from last night, "Is the expected behaviour documented anywhere?"

It is.  RIGHT IN THE FUNCTION COMMENTS!

/**
 * Attempts to detect CRT presence through any method available.
 *
 * @param allow_disturb enables detection methods that may cause flickering
 *        on active displays.
 */

With that word "any" right there, exiting early in the EDID detection, reporting 'Disconnected' WITH ANY MONITOR CONNECTED is a failure to meet the stated driver requirement.

Moving the goto up 4 lines solves the issue, and satisfies the *through any method available* requirement.

Unless the comments are wrong, of course ;)

I agree we should try best with any method available, which means I agree with your patch in that sense. But I'm concerned if hotplug detect tells the correct result when VGA isn't connected. With your patch, we'll try next for ddc and load_detect, that might cause wrong VGA detect in some unusual display config, like on mac mini or some DVI-I output.

Maybe we can add an option to try your method. Could you also send your patch to
intel-gfx@lists.freedesktop.org? Keith/Eric/Jesse are all on that list for review patches, they might have better idea of this. Thanks.

i830_crt_detect_hotplug() should be correct -- if it returns false, that should actually be the case.  "tries every method available even when one conclusively reports disconnected" is certainly not the intent of the comment I wrote.

Removing the KVM and seeing if that's confusing the hotplug detect would be the first step in figuring out what's going wrong.  If removing the KVM helps, it may be interesting to see what setting other hotplug_en bits (CRT_HOTPLUG_ACTIVATION_PERIOD_64, other VOLTAGE_COMPAREs) do with the KVM in.

we do have a case that a too long VGA cable cause EDID failure. see bug# 15155. Please double check that.

"If not use KVM, does your 945G's CRT can detect right?"

Without the KVM, going directly from PC to LCD, with the stock driver it works fine.

Created attachment 21027 [details]
Shows proper EDID detection  w/o KVM w/ stock RPM driver.

"Removing the KVM and seeing if that's confusing the hotplug detect would be the
first step in figuring out what's going wrong."

That does appear to be the case.

"If removing the KVM helps, it may be interesting to see what setting other hotplug_en bits (CRT_HOTPLUG_ACTIVATION_PERIOD_64, other VOLTAGE_COMPAREs) do with the KVM in."

Could you provide brief instructions on how how to alter those bits  and test?

we didn't claim to support KVM case. since it works without KVM, WONTFIX this bug. thanks.

Why on Earth wouldn't you support a configuration with a KVM and/or NOT PROPERLY DOCUMENT THIS LACK OF SUPPORT?

1) The EDID is simply broken as it ***DID NOT DETECT*** the connected VGA Monitor but ***REPORTED*** that none was connected. ( Either the *detection* or the *logging* fails to tell the simple truth.  

2) If the broken behaviour is accepted to be "good enough", then the existing comments are all wrong, because the comments indicate that the code should fall through and try DDC and Load Detect.

3) And fix your other documentation to indicate the KNOWN FAILURE to properly operate, and save some other schumck like me a week screwing around pointlessly fixing these simple errors.

4) Your welcome.

in http://intellinuxgraphics.org/how_to_report_bug.html, Section 4 Tips, we've asked our bug reporter not to connect via a KVM. You're right. We should consider add it to our release note or other documents.

Hey, that's a useful link.  

I wonder why I've never seen any reference to that page before?

Since my bug report didn't really follow any of those guidelines, perhaps you could have pointed me in that direction earlier?

Of course, we all plainly know that I should never even had to file a bug report for this if the driver wasn't broken and didn't outright lie about the lack of a monitor, when one was connected.

Pointing to a troubleshooting step to justify a failure to fix a broken driver as an excuse is pretty lame.

Thanks for the suggestion, Mike. We should consider place a pointer to that page on intelinuxgraphics.org main page, so that everyone goes to the side would notice this.... thanks!

Here's a radical idea.  Put the URL in the LOGFILE, where people will actually see it.