intel video driver regression rev53561 -> rev53790

[hugeping]

Just updated from rev53561 to rev53790.
After booting have black screen. ctrl-alt-del did reboot. Selecting fail-safe video driver -> worked.
But rev53561 worked fine with accelerated driver...

listdev:
device Display controller (VGA compatible controller, VGA controller) [3|0|0]
  vendor 8086: Intel Corporation
  device 0166: 3rd Gen Core processor Graphics Controller

[pulkomandy]

Please attach a syslog. Also, it would be helpful if you could try some intermediate revisions, and try to find the last working/first broken ones.

[hugeping]

Ok, i have attached log and patch on master that solves problem on my side. Hope, it helps.

[ambroff]

I don't understand why yet but I can confirm that reverting ​03ee42a8e resolves the issue for my Ivy Bridge laptop as well.

[pulkomandy]

Good to know, but I think it's needed for my SandyBridge one to work. I'll see what I can find.

[pulkomandy]

So, here is a short explanation of what this code does:

The intel video hardware has two display "pipes". These are set with the timing and source image for each of the two displays that can be used at the same time (later generations add a 3rd pipe to have 3 independant displays).

The pipes can be freely mapped to the output ports (lvds, dvi, vga, ...). So you can have two displays using the same pipe (and displaying the same thing), or you can have two displays each using a separate pipe.

Previously we would always return INTEL_PIPE_B for the LVDS (internal flat panel) port here. Then, we would try to program the LVDS port to use pipe B. But, it turns out our code to change which display pipe is used doesn't quite work.

So, we would end up in an interesting situation: we would configure pipe B, but let the LVDS display show the output of pipe A, which was set by the VESA driver. Of course this would normally not work very well, however...

Even when configuring pipe B, we did reset some of pipe A registers (the old versions of the driver used to just set both pipes to the same things regardless of connected monitors, hoping that one would be connected to some display, and there were some leftovers of that). We did set just what we needed for pipe A to show the right thing, and left pipe B in a badly configured state (because we couldn't see what we were doing to it, and it seemed to work because pipe A was OK and shown on display).

So, what I did here is read from the "port register" which has a bit telling us which pipe is currently used. And we just tell the driver to reuse that one. This way we can save us all the work of switching the display from one pipe to the other, which we don't do correctly.

So, I would guess that something is wrong on Iron Lake with the way we set up pipe B, and reverting this change gets us back to the initial situation: a broken setup on pipe B, but the display is showing pipe A anyway which was set y VESA so it doesn't really matter. I would review all parts of the modesetting for things that I made sandybridge specific when in fact they should also apply for iron lake (so check for Generation >= 6 or so, and verify the Iron Lake intel specs to see if it should instead be >= 5 ; check places where the PCH versions are not handled the same, etc).

[pulkomandy]

See my comment in https://dev.haiku-os.org/ticket/15661#comment:16, it looks like your computer also uses Panther Point and simple changes I suggested there will fix the issue.

[pulkomandy]

Please test hrev53857, issue should be fixed there.

[hugeping]

Replying to pulkomandy:

Please test hrev53857, issue should be fixed there.

Works fine!