Description (enter button submitted the bug too early):

An an IBM SurePOS 566 with an Intel 82Q35 graphics chipset and a 15" display (touchscreen) attached to it, the primary video does not work.  Instead, at an early stage in the boot stage, the output switches to the external VGA output (to which I connected a monitor).  This is the part of the dmesg where I added a comment:

[...]
usb 1-5.2: new full speed USB device using ehci_hcd and address 3
usb 1-5.2: New USB device found, idVendor=05ba, idProduct=000a
usb 1-5.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-5.2: Product: U.are.U® 4500 Fingerprint Reader
usb 1-5.2: Manufacturer: DigitalPersona, Inc.
usb 1-5.2: SerialNumber: {3740B292-0CE7-0C45-BFC2-5053D2C76391}
fbcon: inteldrmfb (fb0) is primary device
###### HERE THE CONSOLE SWITCHES FROM PRIMARY TO SECONDARY DISPLAY !!! ######
Console: switching to colour frame buffer device 160x64
fb0: inteldrmfb frame buffer device
registered panic notifier
No ACPI video bus found
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[...]

This is on Fedora 13 with xorg-x11-drv-intel 2.11.0.  The same problem occurs on RHEL6 beta2 and OpenSUSE 11.3 can't even do X at all (not even on the secondary display).  SLED 11 (using an older 2.6.27 kernel) works fine with the intel driver.

I will add full dmesg output etc. as attachments to this bug.

Created attachment 37689 [details]
Fedora 13 dmesg output with drm.debug=0xc

Created attachment 37690 [details]
Fedora 13 Xorg.0.log 

Note that this is the log for the X session running on the seconday display, where I connected a 1280x1024 display to the external VGA output.

Created attachment 37691 [details]
Fedora 13 xrandr --verbose output

Note that X was running on the secondary, external monitor.

Created attachment 37692 [details]
SLED 11 xrandr --verbose output

Note that X was running here on BOTH the internal 1024x768 display and on the secondary 1280x1024 display.  If you want me to disable the external display for the test, let me know.

Out of curiosity whilst I have a read of the code to see what happened, can you try a rawhide kernel just on the off-chance that we now successfully read the EDID?

Created attachment 37693 [details] [review]
Persevere without a fixed mode

This should help with the secondary issue of failing to do anything with a SDVO LVDS panel without reading the EDID. But the real bug is not reading the EDID/VBT successfully in the first place.

Latest Fedora rawlihide kernel (2.6.36-0.0.rc0.git1.fc15.i686) does not seem to change anything.

Created attachment 37818 [details] [review]
Guess DDC bus without VBIOS

Looks very similar to bug 29499.

These 4 patches use the VBT from the OpRegion (and fixup a couple of surrounding bugs) which should be more reliable than scanning the PCI ROM for the VBIOS:

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=drm-testing&id=781897baae5cf54acf974796ce58967885d0d02c

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=drm-testing&id=88fb6fcbabd4a620da7187baa0ffb3ab9b80d8f2

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=drm-testing&id=4eac606c64ed300925409f6dc325901b7c4e542c

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=drm-testing&id=044346593c4a5deb33b7791a58b9d3327c64f4e1

I've sent the patches upstream, http://cgit.freedesktop.org/~ickle/drm-intel/log/

(In reply to comment #11)
> I've sent the patches upstream,
> http://cgit.freedesktop.org/~ickle/drm-intel/log/

Is there an easy way I can test this on my HW with F13 (or RHEL6beta2)?  With 
"easy" I mean for example a patch that applies to one of the latest F13 kernels, so that I rebuild the kernel rpm with that patch.

You can try downloading the tree and doing:

$ cp /boot/config-2.6.x .config
$ make oldconfig
$ make
$ make rpm

I'm not sure just how easy it would be patch the F13 kernel, you might want to poke a friendly fedora kernel maintainer. Let me compile a single patch with the relevant fixes and hope it applies to F13...

Created attachment 38473 [details] [review]
Compilation patch

I think the "37818: Guess DDC bus without VBIOS" is sufficient to fix your issue by itself, but hopefully this patch finds the correct VBIOS.