Created attachment 142048 [details] display not turned on by kernel on boot DRM tip tree, commit 90b59df999a1 ("drm-tip: 2018y-10m-15d-20h-57m-27s UTC integration manifest") Fedora 28 system on an HP EliteBook Folio G1 with Intel(R) Core(TM) m7-6Y75 CPU, x86_64 of course. I have two external monitors connected: * one directly by USB-C display port cable * one via docking station (https://www.iogear.com/product/GUD3C01/), connected with HDMI During boot, where you enter the disk password, and the Fedora logo is displayed, the second one stays blank. It does come out of powersave, but stays blank rather than showing the Fedora logo and password entry etc. It comes on properly when GDM starts up. See the two attached images - one with the fedora boot logo, the other with the GDM screen (the actual input screen is on the laptop display, so not visible). This is a regression, but I cannot exactly say when it was introduced. I know it works on 4.13 (I installed this due to the other bug I'm about to file), and I believe it still worked on 4.15, but I don't have that installed now to test.
Created attachment 142049 [details] display turned on by gdm
Created attachment 142051 [details] dmesg log (captured via journalctl as 1M log buffer wasn't enough)
Created attachment 142052 [details] vbios dump
Would be nice to attach also Xserver and gdm logs to see if they got correspondent uevents and got connector states updated properly. There are no such problems with Ubuntu 16/18 at least with the same kernel. I've seen a similar bug and the problem was that gdm sometimes simply didn't initiate modeset for some connectors. From the logs I see here: cat bug-108460.log | grep -iE "(status updated)|(mode_setcrtc)|(session opened for user)" Oct 16 23:24:53 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:83:eDP-1] status updated from unknown to connected Oct 16 23:24:53 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:91:DP-1] status updated from unknown to disconnected Oct 16 23:24:53 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:102:DP-2] status updated from unknown to connected Oct 16 23:24:54 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:149:DP-3] status updated from unknown to connected Oct 16 23:24:54 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:109:DP-4] status updated from unknown to disconnected Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:45:pipe A] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:83:eDP-1] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:45:pipe A] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:83:eDP-1] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:63:pipe B] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:102:DP-2] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:63:pipe B] Oct 16 23:24:55 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:102:DP-2] Oct 16 21:25:26 jberg1-mobl2.ger.corp.intel.com systemd[1520]: pam_unix(systemd-user:session): session opened for user gdm by (uid=0) Oct 16 21:25:26 jberg1-mobl2.ger.corp.intel.com gdm-launch-environment][1456]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0) Oct 16 21:25:30 jberg1-mobl2.ger.corp.intel.com systemd[1831]: pam_unix(systemd-user:session): session opened for user jberg1 by (uid=0) Oct 16 21:25:30 jberg1-mobl2.ger.corp.intel.com sshd[1716]: pam_unix(sshd:session): session opened for user jberg1 by (uid=0) Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:45:pipe A] Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:83:eDP-1] Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:63:pipe B] Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:102:DP-2] Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CRTC:81:pipe C] Oct 16 21:25:38 jberg1-mobl2.ger.corp.intel.com kernel: [drm:drm_mode_setcrtc [drm]] [CONNECTOR:149:DP-3] As you can see the kernel updates status to connected for eDP-1, DP-2, DP-3, but we get drm_mode_setcrtc only for eDP-1, DP-2 before you login. Then we finally get drm_mode_setcrtc for all of the connectors, after login. drm_mode_setcrtc is initiated by DRM_IOCTL_MODE_SETCRTC ioctl which sent from XServer after gdm requests it.Kernel doesn't initiate it by itself. Also I bet xrandr would show that all connectors are in connected state - then this is most likely more a gdm/XServer issue, rather than kernel.
(In reply to Stanislav Lisovskiy from comment #4) > Would be nice to attach also Xserver and gdm logs to see if they got > correspondent uevents and got connector states updated properly. > There are no such problems with Ubuntu 16/18 at least with the same kernel. > I've seen a similar bug and the problem was that gdm sometimes simply didn't > initiate modeset for some connectors. Wait, I'm talking about boot, I don't think Xserver/gdm are relevant? This is what happens directly after grub, basically. You don't have anything but initramfs, I'd be very surprised if Fedora was putting Xserver and/or gdm there. Though perhaps I could check what happens if I make the boot non-quiet, and let boot messages scroll through - I suspect they will only show up on one external screen too.
(In reply to Johannes Berg from comment #5) > (In reply to Stanislav Lisovskiy from comment #4) > > Would be nice to attach also Xserver and gdm logs to see if they got > > correspondent uevents and got connector states updated properly. > > There are no such problems with Ubuntu 16/18 at least with the same kernel. > > I've seen a similar bug and the problem was that gdm sometimes simply didn't > > initiate modeset for some connectors. > > Wait, I'm talking about boot, I don't think Xserver/gdm are relevant? > > This is what happens directly after grub, basically. You don't have anything > but initramfs, I'd be very surprised if Fedora was putting Xserver and/or > gdm there. > > Though perhaps I could check what happens if I make the boot non-quiet, and > let boot messages scroll through - I suspect they will only show up on one > external screen too. You are right, this is actually a bit different. I will check on how it should behave in that case.
(In reply to Stanislav Lisovskiy from comment #6) > You are right, this is actually a bit different. I will check on how it > should behave in that case. Fair enough, I guess, it used to display on all screens. I can't really say it bothers me tremendously, even if I typically use the one that goes blank as my "main" screen I can certainly enter the boot password anyway :-)
(In reply to Johannes Berg from comment #7) > (In reply to Stanislav Lisovskiy from comment #6) > > > You are right, this is actually a bit different. I will check on how it > > should behave in that case. > > Fair enough, I guess, it used to display on all screens. I can't really say > it bothers me tremendously, even if I typically use the one that goes blank > as my "main" screen I can certainly enter the boot password anyway :-) FWIW, as of 4.17-rc5 (commit 10cfc747835e34c) which I'm randomly running now while trying to bisect bug 108462, it still turns on both screens during boot.
Ok, hmmm. This depends on the kernel .config, now with the current config ("make localmodconfig") on the same DRM tip tree (commit 90b59df999a1) it works fine ... One (perhaps significant) difference that I notice it that this kernel now shows the 4 boot-time penguins, which is not the case on Fedora's config. Any thoughts as to what Kconfig knobs might affect this that I can play with? Then perhaps with that I can even bisect the issue, but first I have to find a non-fedora config (it takes too long to compile...) that actually has it!
So I've found a kernel .config where the external screens *both* aren't even turned on, I've attached both a good (except for sound) config, and a bad (no external screens at all) config to bug 108462, the diff between them is simple: +CONFIG_REGMAP_I2C=m +CONFIG_SND_HDA_EXT_CORE=m +CONFIG_SND_SOC=m +CONFIG_SND_SOC_TOPOLOGY=y +CONFIG_SND_SOC_ACPI=m +CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y +CONFIG_SND_SOC_INTEL_SST=m +CONFIG_SND_SOC_INTEL_SKYLAKE=m +CONFIG_SND_SOC_ACPI_INTEL_MATCH=m +CONFIG_SND_SOC_INTEL_MACH=y +CONFIG_SND_SOC_I2C_AND_SPI=m
Stan, any comments here?
So, I'm unable to figure out what's going on, but with the new kernel I installed recently (4.19.13) this issue appears to be fixed. Of course I don't know if Fedora just changed the default config or if there really were any code changes ... (remember that I never was able to figure out the particular Kconfig setting that _broke_ it to start with)
(In reply to Johannes Berg from comment #12) > So, I'm unable to figure out what's going on, but with the new kernel I > installed recently (4.19.13) this issue appears to be fixed. Of course I > don't know if Fedora just changed the default config or if there really were > any code changes ... (remember that I never was able to figure out the > particular Kconfig setting that _broke_ it to start with) Thanks for the feedback. We always recommend to update kernel to latest, that did the trick. Closing this bug.
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.