Bug 100213

Please boot with drm.debug=0xe and attach the full dmesg from boot all the way when the display is detected by the igpu.

Also please attach the EDID from the display.

Created attachment 130234 [details]
journal with drm.debug=0xe

Created attachment 130235 [details]
cat /sys/class/drm/card0-DP-2/edid

Created attachment 130236 [details]
journal with drm.debug=0xe ("discrete")

Changed to "Discrete Graphics" in BIOS. Unfortunately kernel did not finish booting and hang somewhere, so previous, about week old, version of drm-tip was used for this test. With this setup, desktop was extended to second display.

Created attachment 130237 [details]
cat /sys/class/drm/card0-DP-2/edid

EDID from "Discrete Graphics" case.

The BIOS boots with a 1024x768 fb:
bře 15 19:21:04 lenoch kernel: [drm:skylake_get_initial_plane_config [i915]] pipe A with fb: size=1024x768@32, offset=0, pitch 4096, size 0x300000

Which we reject, presumably due to the "don't use the first 4k of stolen" thing:
bře 15 19:21:04 lenoch kernel: [drm:i915_gem_object_create_stolen_for_preallocated [i915]] creating preallocated stolen object: stolen_offset=0, gtt_offset=0, size=300000
bře 15 19:21:04 lenoch kernel: [drm:i915_gem_object_create_stolen_for_preallocated [i915]] failed to allocate stolen space

Then we detect that eDP-1 is connected:
bře 15 19:21:04 lenoch kernel: [drm:intel_dp_detect [i915]] [CONNECTOR:48:eDP-1]
bře 15 19:21:04 lenoch kernel: [drm:intel_dp_detect [i915]] Display Port TPS3 support: source yes, sink no
bře 15 19:21:04 lenoch kernel: [drm:intel_dp_print_rates [i915]] source rates: 162000, 216000, 270000, 324000, 432000, 540000
bře 15 19:21:04 lenoch kernel: [drm:intel_dp_print_rates [i915]] sink rates: 162000, 270000
bře 15 19:21:04 lenoch kernel: [drm:intel_dp_print_rates [i915]] common rates: 162000, 270000
bře 15 19:21:04 lenoch kernel: [drm:intel_dp_read_desc [i915]] DP sink: OUI 00-00-00(NS) dev-ID  HW-rev 0.0 SW-rev 0.0

But the somehow drm_setup_crtcs() fails to probe eDP-1 modes. it does seem to probe the external connectors again, but not eDP-1 for some reason. I can't think of any reason it could skip eDP-1. And finally it settles for a 1024x768 fb:
bře 15 19:21:04 lenoch kernel: [drm:drm_setup_crtcs [drm_kms_helper]] picking CRTCs for 16384x16384 config
bře 15 19:21:04 lenoch kernel: [drm] Cannot find any crtc or sizes - going 1024x768

Which then causes the fb_helper to reject any mode larger than 1024x768 for DP-2:
bře 15 19:22:25 lenoch kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:55:DP-2] probed modes :
bře 15 19:22:25 lenoch kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 86:"720x576" 50 27000 720 732 796 864 576 581 586 625 0x40 0xa
bře 15 19:22:25 lenoch kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 121:"720x480" 60 27027 720 736 798 858 480 489 495 525 0x40 0xa
bře 15 19:22:25 lenoch kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 84:"720x480" 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
bře 15 19:22:25 lenoch kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 116:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa
bře 15 19:22:25 lenoch kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 76:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa

And thus you're left with a low resolution fbcon. Starting X/etc. would allow you to see the higher resolutions as well. However there is definitely something fishy going on when fb_helper fails to probe the eDP-1 modes.

Created attachment 130739 [details]
journal with drm.debug=0xe

Retested todays drm-tip

With the same kernel as in comment 7 I once got:
[drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 80
Tried to reproduce it with debug enabled, but no luck so far.

(In reply to Ladislav Michl from comment #8)
> With the same kernel as in comment 7 I once got:
> [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual
> mode adaptor ID 80
> Tried to reproduce it with debug enabled, but no luck so far.

Hello, have you been able to reproduce? The bug is still valid? Thanks.

Created attachment 132468 [details]
4.12 boot log with drm.debug=0xe

(In reply to Elizabeth from comment #9)
> Hello, have you been able to reproduce? The bug is still valid? Thanks.
Bug is still valid, never seen error from comment #8 again.
Attached bootlog from 4.12.0 - hdmi connector connect-disconnect captured in log.

(In reply to Ladislav Michl from comment #10)
Thanks for the update. If any new information is required it will be commented below.

Hello Ladislav, were you able to workaround this using the startx mentioned by Ville at comment 6??

Elisabeth, all tests were done while Wayland was running. I'm not using X on this machine. Also, I'm able to test any proposed patch, even instantly once any developer gets interested enough.

First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Retested with 4.16.0 and 4.16.0-next-20180409

Machine has HDMI and VGA connector:
https://www.exasoft.cz/hp-zbook-17-g3-1rq40es-bcm-cerna-image1-big_ies1790841.jpg

$ cat /sys/class/drm/card0/device/graphics/fb0/name
nouveaufb
$ cat /sys/class/drm/card1/device/graphics/fb1/name 
inteldrmfb

Plugging monitor into VGA output gives:
$ grep . /sys/class/drm/card*-*/modes
/sys/class/drm/card1-DP-3/modes:1920x1200
/sys/class/drm/card1-DP-3/modes:1600x1200
/sys/class/drm/card1-DP-3/modes:1280x1024
/sys/class/drm/card1-DP-3/modes:1280x1024
/sys/class/drm/card1-DP-3/modes:1152x864
/sys/class/drm/card1-DP-3/modes:1024x768
/sys/class/drm/card1-DP-3/modes:1024x768
/sys/class/drm/card1-DP-3/modes:800x600
/sys/class/drm/card1-DP-3/modes:800x600
/sys/class/drm/card1-DP-3/modes:640x480
/sys/class/drm/card1-DP-3/modes:640x480
/sys/class/drm/card1-DP-3/modes:720x400
/sys/class/drm/card1-eDP-1/modes:1920x1080
/sys/class/drm/card1-eDP-1/modes:1920x1080
Here everything works as expected.

Plugging the same monitor to HDMI output:
$ grep . /sys/class/drm/card*-*/modes
/sys/class/drm/card0-DP-5/modes:1920x1200
/sys/class/drm/card0-DP-5/modes:1600x1200
/sys/class/drm/card0-DP-5/modes:1280x1024
/sys/class/drm/card0-DP-5/modes:1280x1024
/sys/class/drm/card0-DP-5/modes:1152x864
/sys/class/drm/card0-DP-5/modes:1024x768
/sys/class/drm/card0-DP-5/modes:1024x768
/sys/class/drm/card0-DP-5/modes:800x600
/sys/class/drm/card0-DP-5/modes:800x600
/sys/class/drm/card0-DP-5/modes:640x480
/sys/class/drm/card0-DP-5/modes:640x480
/sys/class/drm/card0-DP-5/modes:720x400
/sys/class/drm/card1-eDP-1/modes:1920x1080
/sys/class/drm/card1-eDP-1/modes:1920x1080
Here monitor goes to sleep as there seem to be no clock. Also It seems I hit this bug:
https://gitlab.gnome.org/GNOME/mutter/issues/21

I tried to get meaningful debug output, but no luck so far.

Created attachment 138717 [details]
4.16.0-next-20180409 VGA connected after boot

Created attachment 138718 [details]
4.16.0-next-20180409 HDMI connected after boot

Hi Ladislav, do you consider issue still existing?

In seems fixed, indeed. Tested with 4.17.0-rc5, secondary screen even works for a few seconds, then gnome-shell crashes:
gnome-shell[1082]: segfault at 1c ip 00007f9737883509 sp 00007ffe3ba3d2e0 error 4 in libglib-2.0.so.0.5600.1[7f973781a000+113000]
As it is obviously unrelated, I'm closing this bug.

And just for completeness, mutter 3.28.2 solves above crash.

Ok, thanks, closing.b