Created attachment 138633 [details]
dmesg output of kernel 4.14.32

Created attachment 138634 [details]
dmesg output of kernel 4.16.0

Created attachment 138635 [details]
xorg log under kernel 4.14.32

Created attachment 138636 [details]
xorg log under kernel 4.16.0

Note that with the 4.16 kernel, Xorg doesn't use the xorg.conf Section Monitor for the second DVI output, because it has a different name. But it looks like the real problem is that DC doesn't detect the monitor connected to it, reassigning.

BTW, does it still work with the 4.16 kernel and amdgpu.dc=0?

(In reply to Michel Dänzer from comment #5)
> Note that with the 4.16 kernel, Xorg doesn't use the xorg.conf Section
> Monitor for the second DVI output, because it has a different name.

I know, but that's unimportant. The  xorg.conf section for the second DVI output only exists such that the default layout of the monitors matches their physical arrangement on my desk. (From left to right, DVI-I tilted upwards, DP and then DVI-D). 

> But it
> looks like the real problem is that DC doesn't detect the monitor connected
> to it, reassigning.

That's it.

> BTW, does it still work with the 4.16 kernel and amdgpu.dc=0?

Yes it does. (But of course with a wrong layout, because DVI-I is renamed to DVI-D-1)

(In reply to Matthias Nagel from comment #6)
> > BTW, does it still work with the 4.16 kernel and amdgpu.dc=0?
> 
> Yes it does. (But of course with a wrong layout, because DVI-I is renamed to
> DVI-D-1)

Really? It's surprising that the output name would change even with DC disabled.

> Really? It's surprising that the output name would change even with DC
> disabled.

Sorry, my fault. I tampered with the xorg.conf to match it the new naming with DC enabled.

BTW, another interesting point:

I use dual-boot with Win10. I have never got the third monitor working with Win10, because the Windows driver does not detect the monitor neither. Initially, it does not appear in the monitor list, if I press the button "Identify" the third monitor pops up as an "Unknown, Not PnP, VGA monitor", but is greyed out. In other words the new Linux DC code behaves more similar to the Windows driver (which of course is not a real advantage).

Can you capture the 4.16 dmesg with DC again with the amdgpu.dc_log=1 module option?

Do you see any activity on dmesg with dc_log=1 when you hotplug the non-detected display?

Created attachment 138677 [details]
dmesg output of kernel 4.16.0 with dc_log=1

Created new dmesg with amdgpu.dc_log=1, but I do not see any changes in output.

And there no kernel message, if I plug/unplug the monitor.

I can confirm the bug ( in my case I have a DVI-I to VGA adapter) 
https://bugs.launchpad.net/bugs/1762259

I appear to have a similar issue, like comment #11, where the DVI-I port on my 380X seems to be detected as DVI-D when DC is on and I don't get display over my DVI-I to VGA adapter (it works fine with amdgpu.dc=0). I'm also on Ubuntu 18.04 and I also still experience this with the latest mainline kernel. The Xorg log (extracts below) does still list the EDID for my display, identifies it as analog, and lists the new DVI-D port as connected when DC is on, but the display doesn't turn on.

DC on:
[     7.312] (II) AMDGPU(0): EDID for output DisplayPort-1
[     7.312] (II) AMDGPU(0): EDID for output HDMI-A-1
[     7.313] (II) AMDGPU(0): EDID for output DVI-D-2
[     7.313] (II) AMDGPU(0): EDID for output DVI-D-3
[     7.313] (II) AMDGPU(0): Manufacturer: SAM  Model: 4e5  Serial#: 1297691186

DC off:
[     7.399] (II) AMDGPU(0): EDID for output DisplayPort-1
[     7.400] (II) AMDGPU(0): EDID for output HDMI-A-1
[     7.402] (II) AMDGPU(0): EDID for output DVI-D-1
[     7.440] (II) AMDGPU(0): EDID for output DVI-I-1
[     7.440] (II) AMDGPU(0): Manufacturer: SAM  Model: 4e5  Serial#: 1297691186

The system still works as expected with both keyboard and mouse, so X does start properly otherwise.
This also happens with AMDGPU-PRO on Ubuntu 18.04 LTS.

I now booted with amdgpu.dc_log=1 and found the following in my log when DC is on (I'm currently on 4.15.0.36):

[    1.479998] [drm] DC: create_links: connectors_num: physical:4, virtual:0
[    1.480001] [drm] Connector[0] description:signal 32
[    1.480029] [drm] Connector[1] description:signal 4
[    1.480031] [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
[    1.480046] [drm] Connector[2] description:signal 2
[    1.480048] [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
[    1.480064] [drm] Connector[3] description:signal 2
[    1.480066] [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!
[    1.492083] [drm] Display Core initialized
[    1.492091] [drm] Display Core initialized!
[    1.492427] [drm] link=0, dc_sink_in=          (null) is now Disconnected
[    1.492555] [drm] link=1, dc_sink_in=          (null) is now Disconnected
[    1.492683] [drm] link=2, dc_sink_in=          (null) is now Disconnected
[    1.505440] [drm] SADs count is: -2, don't need to read it
[    1.505453] [drm] [Detect]	[DDVI][ConnIdx:3] EDID goes here
[    1.505455] [drm] dc_link_detect: EDID decoded goes here
[    1.505456] [drm] link=3, dc_sink_in=        (ptrval) is now Connected

This does seem to show that connector 3 is incorrectly identified as dual link DVI-D, or at least missing/not using the analogue part.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/343.