Created attachment 141642 [details] Linux 4.19-rc4+ (drm-tip) messages Using the MST display Dell UP3214Q connected over DisplayPort, with at least Linux 4.14, Linux 4.18.6, and drm-tip, the early Linux messages are not shown on the screen. Note, that the firmware of the Fujitsu system is not able to initialize the display, so neither the Fujitsu logo nor the GRUB menu is visible. (Legacy boot is used.) Despite these issues, the early Intel driver should display something in fallback mode. Can this be done? Please find the logs attached.
A couple of angles to approach from: 1. We should try to capture the log for fbcon for eventual display even if no display is available at that time. However, fbcon/fbdev is really lower priority than seamless transition from boot to desktop. 2. Dramatically speed up DP-MST discovery.
Created attachment 144206 [details] Linux 5.1 messages (dmesg) This still happens with Linux 5.1. Display blank during firmware until GDM. `systemctl restart gdm` does *not* help. Plugging the cable from DP1 to DP2 and `systemctl restart gdm` activates monitor and GDM login screen is visible. Can you see anything in the debug logs?
The first modeset happens at ~18 seconds. i915 probe started at ~17 seconds. So doens't look like probe being slow is the issue here. I suspect the problem is these guys: [ 18.297317] [drm:drm_dp_dpcd_write_payload.isra.11 [drm_kms_helper]] status not set after read payload table status 0 So the display itself is maybe in some wonky state after the BIOS manhandled it. After the replug (at ~67 seconds) the display responds correctly to our gentle prodding and that error is no longer visible. I think this may be due to the BIOS doing something odd, or it may have something to do with the fact that we don't have readout code for MST so we may not be shutting things down properly when taking over.
-- 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/intel/issues/159.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.