Intel HD Graphics 2000: black screen on VGA out

[vidrep]

hrev52136 x86_gcc2h

Intel HD Graphics 2000

Sandy Bridge [HD Graphics GT1]

Device 8086:0102

Native resolution of monitor is 1680x1050

After rocket icon only a black screen.

[vidrep]

Native resolution of monitor (1680x1050) is not supported by VESA driver either.

[pulkomandy]

1898	intel_extreme: CALLED status_t init_hardware()
1899	package_daemon [15458676:   500] intel_extreme: CALLED status_t init_driver()
1900	active package: "cdrtools-3.02~a09-1-x86_64.hpkg"
1901	package_daemon [15474072:   500] active package: "tar-1.29-3-x86_64.hpkg"
1902	[36mAGP:[0m bus manager init
1903	package_daemon [15480564:   500] [36mAGP:[0m found 0 AGP devices
1904	active package: "openssl-1.0.2o-1-x86_64.hpkg"
1905	intel_extreme: detect_intel_pch: Found CougarPoint PCH
1906	package_daemon [15493386:   500] intel_extreme: (0) SandyBridge Desktop GT1, revision = 0x9
1907	active package: "mesa_swpipe-17.1.7-8-x86_64.hpkg"
1908	intel_extreme: CALLED const char** publish_devices()
1909	package_daemon [15510806:   500] intel_extreme: CALLED device_hooks* find_device(const char*)
1910	active package: "libtheora-1.1.1-7-x86_64.hpkg"
1911	loaded driver /boot/system/add-ons/kernel/drivers/dev/graphics/intel_extreme

These are the only references to the intel_extreme driver. It apparently found a PCH, but no device? How can we end up with a black screen because of it then?

[vidrep]

I managed to grab a serial log, which I've attached. It may have the information you're looking for.

[pulkomandy]

The end of the serial log:

2114	intel_extreme: intel_set_display_mode(1680x1050)
2115	[33musb_asix:[0m00.17.251:init_driver::ver.0.10.1
2116	loaded driver /boot/system/add-ons/kernel/drivers/dev/net/usb_asix
2117	intel_extreme: IsConnected: Analog A PortRegister: 0x5001100
2118	intel_extreme: CALLED void Pipe::Enable(bool)
2119	[36mAGP:[0m create memory 0x82b6f420, base e0010000, size 6bb000, flags 0
2120	[36mAGP:[0m allocation is made of reserved memory
2121	[36mAGP:[0m reserved memory already bound
2122	intel_extreme: IsConnected: Analog A PortRegister: 0x5001100
2123	intel_extreme: SetDisplayMode: Analog A 1680x1050
2124	intel_extreme: CALLED status_t FDILink::Train(display_mode *)
2125	intel_extreme: Train: FDI Link Lanes: 2
2126	intel_extreme: CALLED void FDIReceiver::EnablePLL(long unsigned int)
2127	intel_extreme: EnablePLL: Already enabled.
2128	intel_extreme: CALLED void FDIReceiver::SwitchClock(bool)
2129	intel_extreme: CALLED void FDITransmitter::EnablePLL(long unsigned int)
2130	intel_extreme: EnablePLL: Already enabled.
2131	intel_extreme: CALLED status_t FDILink::_SnbTrain(long unsigned int)
2132	intel_extreme: CALLED void FDIReceiver::Enable()

This looks strange, we are trying to set a display mode so at this point we should be configuring the PLLs for the right mode. But instead it says "already enabled" and does nothing.

[vidrep]

PulkoMandy, I updated both PC's to latest build (hrev52280), which now includes your changes to the Intel_extreme driver. I grabbed a serial debugging log of each PC. Attached is the log for this particular Intel graphics chipset (8086:0102.txt). What is odd is that the boot process appears to stall when initializing the graphics and does not go any further. Whereas, the other PC with chipset (8086:0152) will completely boot, although with a black screen. I will attach the log for that PC here: https://dev.haiku-os.org/ticket/13669

[waddlesplash]

Please retest after hrev53040.

[vidrep]

I still have a black screen after updating to hrev53042.

[pulkomandy]

Please try ​https://review.haiku-os.org/c/haiku/+/1899

I have prebuilt a (32bit) accelerant in case you don't want to build Haiku yourself: ​http://pulkomandy.tk/drop/intel_extreme_14301.accelerant

[vidrep]

I've attached a summary of the syslog using the pre-build binary.

[waddlesplash]

Change was merged in hrev53551.

[vidrep]

hrev53555 x86_64

Still black screen after update.

syslog attached

[pulkomandy]

Move tickets that will not be solved in beta2 to beta3.

[pulkomandy]

No one is working on the intel driver at the moment so it seems no progress will be made on these issues for beta3. Remove them from the milestone so we can better see our status.

[vidrep]

Attached are two photos of my screen using the WIP Intel_extreme driver. Native resolution of the screen is 1920x1080 at 60Hz. The refresh rate at the right end of the slider is 60Hz. Moving it to lower refresh rates causes the screen to shift to the left and the foldover on the right side worsens.

First, 1920x1080 at 60Hz

Second 1280x1024 at 60HZ

[rudolfc]

Can you please test the second WIP driver version for me? Does it kill your screen again, or does it improve maybe? Thanks!

File: ​http://www.rudolfs-place.nl/Haiku/Downloads/Intel_extreme_drv_v2_32bit.zip

[vidrep]

No change

[rudolfc]

Another question: compared to the current GIT version: was there improvment on this system? i.e. did you have no picture before, and now you do have a picture? Can you describe the differences for me?

[vidrep]

In the case of this system, the screen was completely black before. Now, I get a desktop, but it is monochrome, and there is a double image type of distortion on the right side of the screen that worsens as the screen resolution is lowered.

[vidrep]

Tested hrev55120 x86_gcc2h with v2 driver on HP monitor 1920x1080@60Hz native resolution. First boot after installing v2 driver resulted in black screen. Ctl+Alt+Del to reboot resulted in monochrome desktop at 1920x1080@60Hz resolution, with double image on right side of screen as before. I have attached syslog and previous syslog from this test.

[vidrep]

I've attached a photo of what my desktop looks like on 64 bit, using the driver changes submitted to master thus far.

[rudolfc]

Thank you. In the meantime I located a SandyBridge system over at my work. I tested it with an analog connected screen and I see approx the same distortions as you are reporting. I'll try to fix these distortions there within a week or so. After that I'll update this ticket and probably have a new driver testversion as well.

[vidrep]

I tested v4 driver on both 32 and 64 bit (hrev55136), using a Dell (1680x1050@60Hz) monitor. All of the preset display resolutions now work on VGA, with the exception of 720x400@70Hz (black screen). On DisplayPort output, setting 1680x1050@60Hz, there is a noticeable overscan of the desktop. 1280x1024@60/75Hz produces a normal desktop. Any lower resolution causes distortion which increases as the resolution is set lower.

[rudolfc]

That's a Nice result. Could you upload a syslog for the digitally connected screen? Thanks!

[vidrep]

Will do. I’ll take some photos of the desktop distortion too.

[rudolfc]

Hi, could you do a test with this card with both monitors connected (one by one) digitally, where the 1920 monitor is connected with the same adapter you just now used on the HD2500?

Please upload the syslogs (so two) from these tests..

[rudolfc]

BTW if it turns out the adapter is an active one, it would be very nice if the test could be repeated with a passive one also if at all possible..

[vidrep]

No, this is a passive DP to HDMI cable.

[rudolfc]

Ok, thanks. In that case the test remains with the 1920 and this adapter so it connect digitally with the HD2000. Please post the resulting syslog.

For the 1680 display connected digitally I am still missing the syslog here, could you upload that?

Also I am thinking I'll test the HD2000 over at my work once more with some more screentypes provided I can find some devices I can use with it. I'll try at least to find a displayport type to see what happens if that's connected directly. I hope I can do this late tomorrow..

[vidrep]

hrev55144 x86_gcc2h v4 Intel_extreme test driver

HD 2000, DP output connected to HDMI monitor input (1920x1080@60Hz) using adapter cable. I cycled through each of the listed preset display resolutions and refresh rates.

syslog attached

[vidrep]

hrev55144 x86_gcc2h v4 Intel_extreme test driver

HD 2000, DP output connected to DP monitor input (1680x1050@60Hz) using DisplayPort cable. I cycled through each of the listed preset display resolutions and refresh rates.

syslog attached

[rudolfc]

OK, we have a pattern here: both of your digital connected monitors are not seen on both the HD2000 and HD2500 (missing EDID/DDC). This needs to be solved (as first item) now. I'll see what I can dig up.

[vidrep]

Updated to hrev55161 and all preset display resolutions are working without any noticeable distortion on VGA output. Thank you for your time and efforts in getting this graphics driver in a working state!

[rudolfc]

Hi, please also test hrev55168 or later on this system for the digital screens (single and together with analog VGA).. Thank you!

[rudolfc]

Here as well: Hello, Could you please test hrev55189 or later for me? I would expect you to always have a desktop, on both screens connected (if so).. I'd like to get a general status update from you so to speak :-) Thank you!

[vidrep]

I have monitor 1 (1920x1080) connected to VGA, and monitor 2 (1680x1050) connected to DP. As long as both are set to a commonly supported resolution (1280x1024), there is a normal appearing desktop on both.

When the screen resolution is not common to both monitors, all I get is a colour bar on the monitor screen, both during boot and afterwards. (see attached photo)

As a side note, I performed this same test on a Dell Optiplex 780 with Intel Q45 graphics, and it is also working OK.

[rudolfc]

Thank you!

[vidrep]

Tested today with hrev55203 x86_64, connected from DP output to DP input on the monitor (no adapter cable). All preset display modes now scale properly to the screen. Nice work! syslog attached.

[rudolfc]

Thank you! super :-)

[rudolfc]

Does this system have a second port btw? could you try with also a VGA screen attached and see what happen, and upload a syslog? That will at least inform me about the BIOS preconfigure, as I am thinking about a way to make that logic work as well..

[vidrep]

One VGA output and one DP output on this PC.

[rudolfc]

OK, nice.

After this, the next version is in git now: hrev55204. I expect dualhead clone mode working with displayport connected screens now.. Please test once the nightly is there :-)

Thanks again!

[vidrep]

In the meantime, I connected both monitors (1920x1080 VGA) and (1680x1050 DP) and upon booting I got the lovely colour bar display I posted a photo of earlier. I then rebooted and selected a display resolution supported by both monitors (1280x1024) and now I have a normal desktop display on both. previous syslog and syslog attached.

[vidrep]

2 questions.

Do you want me to repeat this with my other PC? https://dev.haiku-os.org/ticket/13669

Do you want to tackle Gen 8 Intel graphics? ;)

[rudolfc]

Thanks! Wait for the new nightly I'd say and see if you can set more modes than only 1280x1024 with a displayport connected screen together with VGA, indeed on both systems. Displayport nicely scales up and down here.. (even above native screen mode :-)

Next up I'll put in a bit time in gen4 displayport as dualhead clone does not work yet there. After that gen8 would indeed be cool, but I need to find a system to test with for that over here as well Otherwise it's not really possible to get that done for me. Same goes for laptops btw I expect.

Good to know I can contact you for further testing at least :-) Thank you!

[rudolfc]

Oh BTW I've seen something strange with the Haiku boot options menu concerning vesa modes you can set. With 32bit Haiku you get a much larger list of modes than with 64bit: on exactly the same hardware (just plugged in another USB stick to boot from)

That, in my opinion, should not be. If at all possible that should be fixed as well, but it's outside of the driver, somewhere else in the (early active) system..

Can you confirm you see this same sort of behaviour on your systems please? (if you have time that is ;-)

[rudolfc]

Hi vidrep, Tonight I had the possibility to test on the Sandybridge again, and I see a (small) regression: currently dualhead clone mode does not work there, at least with HDMI and VGA together (Haiku now boots on HDMI and switches to VGA with the desktop. Do you see this as well? In a approx. a week I will be able to test again, and I will update the driver to fix this: looks like on Sandy bridge it's possible to switch pipes actively after all (at least the VGA pipe) where this does not work as far as I know atm with Ivy bridge. So I am going to doublecheck this behaviour on both chipsets then and add another update to the driver.

Anyhow: please let me know if hrev55204 changes behaviour for you, or if it's still the same (dual screens). Maybe upload a syslog again.. Thanks!

[vidrep]

Do you still want me to upload a syslog? The PC I have has VGA and DP output only. I can connect to HDMI with a DP to HDMI adapter if necessary.

[rudolfc]

So I did not yet fix the regression I mentioned here, so the question remains. Also it's interesting to know if a DP screen would switch resolutions correctly here (by scaling) as that's currently implemented if all is right.

[rudolfc]

Hi, just a quick heads-up from my side for now:

In the meantime I have been testing on the HD2000 over at work to see if the pipe-choice at driver startup was the cause for the 'regression' I mentioned before. It was not. Also tested reverting a number of other changes I did to see if I'd get two screens ON again.

That also did not happen. My conclusion about the dualhead thing is that it must have worked on this system at some point because of lacking programming in the driver. There are no faults that cause it at least.

This means I will work some more on other aspects of the driver soon I think. In the end, if I ever get the pipe-link training to work, the dualhead thing comes into play again I expect.

That's it for now.

[vidrep]

hrev55399 x86_64. VGA to 1920x1080 monitor, DP to 1680x1050 monitor. Boot screen and Haiku boot menu appearing on both VGA and DP. Once booted both monitors display the desktop at their native resolutions. syslog attached.

[vidrep]

Can this ticket be closed, or is there more to be done?

[waddlesplash]

No, I think we can consider it fixed, then. :)