[intel_extreme] implement DVI support

[diver]

After the last boot icon the monitor switches off, booting in safe graphics mode works fine.

lspci | grep VGA:
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)

[diver]

Still here in hrev35569.
Anything I could do to provide additional information at this one?

[diver]

Switching from DVI to VGA fixes this problem. Is that a known missing feature in intel_extreme driver or should I try to get two syslogs from booting with DVI and booting with VGA? I would like to help to rule out this problem.

[diver]

syslog from fully booted Haiku using VGA output

[diver]

syslog from session using DVI output where monitor turned off

[diver]

Strange thing is that syslog from DVI is twice as large as syslog from VGA, hmm...

[axeld]

DVI output is not yet supported.

[diver]

(In #8474) Try to enable ​Use fail-safe video mode. DVI is not yet supported, see #5221 and I think the same is true for HDMI.

[axeld]

(In #8474) The crash certainly has nothing to do with #5221, even if that one will probably finally prevent the driver to work as well.

[kallisti5]

I'm still not sure exactly how Intel ties GPIO pins to connectors and encoders... but here is the rough idea:

Most of the monitor detection in intel_extreme seems like a hack. The accelerant uses what the bios powers up at boot... if your attached monitor isn't on at boot, we will never find it.

The edid part of the accelerant only looks at the lvds and analog GPIO pins. (fixed GPIO_IO pin A and C)

I'm attaching a patch. I don't have any intel_extreme devices that have DVI output so I can't fully test. The patch however doesn't break my IvyBridge mode setting.

The strange thing is that the accelerant really doesn't tie the GPIO pins to the connectors in any way.. we kind of just "look for a valid EDID" and go with it once we find it. We then set it on the display in code that isn't linked to where the EDID was found. (thus no real probing of attached displays occurs)

I can safely say that multi-monitor would never work with how intel_extreme is designed at the moment :)

[kallisti5]

Probe all GPIO pins, rev 1

[jessicah]

Ooooh! I manually applied this diff to current intel_extreme driver, and whilst the display still turns off (this is HDMI output => DVI monitor via adapter), I'm actually getting EDID info from the accelerant! Previously it failed.

Following trace is output: intel_extreme accelerant:found edid data on gpio 'dpd'

The rest of the data output by the intel_extreme accelerant looks legit.

[jessicah]

Updated patch against hrev47853

[pulkomandy]

A little bit of history here: originally the intel driver only polled GPIOs on line A for EDID. This didn't work on my laptop (Dell Inspiron 1525) and during BeGeistert 2009 Axel helped me debug this and we added polling line C to fix this one machine. However, this also broke things on some other setups.

The current solution is to scan both lines A and C, and if we find something there, we use it. If no EDID data is found there, we have a fallback solution, which consists of reusing the EDID from VESA. This was later extended with extracting information about the LVDS panel directly from the Intel VGA BIOS.

As a result on my new Core-i3 machine:

• HDMI output is working fine, using EDID from VESA
• VGA is not working (black screen)
• I did not test DVI, no appropriate cable available
• If I have both HDMI and VGA plugged, the EDID is read from the VGA port and applied to the HDMI one. This results on misaligned screen (about 1/3 of the screen is left black, and remaining part of the picture is shifted so DeskBar is somewhere on the middle of the screen). Still no VGA output.

So I don't know if scanning all ports is a good idea, in the current state the VESA/VBT probing is getting the right resolution in most cases. It has the downside that it only adds a single mode and does not know the exact display timing constraints, however.

[jessicah]

Well, I actually have this exact issue on my machine. And prior to the patch, it failed to read anything, and did the VESA fallback.

However, with this patch applied, it correctly reads the EDID data without the VESA fallback.

In both cases, however, the display still turns off. I have to disable the intel_extreme driver and use the vesa driver to get graphics output.

My newer intel_extreme based device works fine (after patching in the requisite device IDs) with HDMI output, but not this device.

[pulkomandy]

Tested it on my machine, and it indeed manage to read the EDID data by itself. The result is exactly the same as when reusing the VESA EDID, in that case.

What we must do is change the order in which we scan the outputs depending on the device:

• VGA: scan port A first
• LVDS: scan port C first
• HDMI: scan D,E or F (not too sure which one is right) first
• DVI: should be the same as HDMI (the protocols are identical except HDMI supports transprting sound, but we don't handle that properly yet).

[pulkomandy]

Patch applied in hrev47864 since it at least doesn't make thins worse.