Opened 9 years ago

Last modified 2 years ago

#5221 assigned enhancement

[intel_extreme] implement DVI support

Reported by: diver Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Graphics/intel_extreme Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #7662
Has a Patch: no Platform: All

Description

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)

Attachments (6)

syslog (242.5 KB) - added by diver 9 years ago.
syslog_r35835_VGA (94.4 KB) - added by diver 9 years ago.
syslog from fully booted Haiku using VGA output
syslog_r35835_DVI (189.7 KB) - added by diver 9 years ago.
syslog from session using DVI output where monitor turned off
intel_extreme.diff (3.9 KB) - added by kallisti5 6 years ago.
Probe all GPIO pins, rev 1
syslog-edited.txt (47.2 KB) - added by jessicah 5 years ago.
0001-intel_extreme-probe-all-GPIO-pins.patch (6.3 KB) - added by jessicah 5 years ago.
Updated patch against hrev47853

Download all attachments as: .zip

Change History (25)

Changed 9 years ago by diver

Attachment: syslog added

comment:1 Changed 9 years ago by diver

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

comment:2 Changed 9 years ago by diver

Version: R1/alpha1R1/Development

comment:3 Changed 9 years ago by 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.

Changed 9 years ago by diver

Attachment: syslog_r35835_VGA added

syslog from fully booted Haiku using VGA output

Changed 9 years ago by diver

Attachment: syslog_r35835_DVI added

syslog from session using DVI output where monitor turned off

comment:4 Changed 9 years ago by diver

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

comment:5 Changed 9 years ago by diver

Summary: [intel_extreme] Q35 monitor switchs off[intel_extreme] Q35 DVI output doesn't work

comment:6 Changed 8 years ago by scottmc

Blocking: 7662 added

comment:7 Changed 8 years ago by axeld

Type: bugenhancement

DVI output is not yet supported.

comment:8 Changed 7 years ago by diver

Summary: [intel_extreme] Q35 DVI output doesn't work[intel_extreme] implement DVI support

comment:9 Changed 7 years ago by diver

Blocking: 8474 added

(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.

comment:10 Changed 7 years ago by axeld

Blocking: 8474 removed

(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.

comment:11 Changed 6 years ago by 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 :)

Changed 6 years ago by kallisti5

Attachment: intel_extreme.diff added

Probe all GPIO pins, rev 1

comment:12 Changed 6 years ago by kallisti5

Has a Patch: set

comment:13 Changed 5 years ago by 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.

Changed 5 years ago by jessicah

Attachment: syslog-edited.txt added

Changed 5 years ago by jessicah

Updated patch against hrev47853

comment:14 Changed 5 years ago by 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.

comment:15 Changed 5 years ago by 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.

comment:16 Changed 5 years ago by 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).

comment:17 Changed 5 years ago by pulkomandy

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

comment:18 Changed 5 years ago by pulkomandy

Has a Patch: unset

comment:19 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.