Created attachment 1711722 [details] dmesg is a log with kernel parameters log_buf_len=50M drm.debug=0x116, state is an output of /sys/kernel/debug/dri/0/state after booting up with only VGA and DP cables connected 1. I use a ThinkPad Thunderbolt 3 Dock with a ThinkPad T580, i7-8650U, UHD Graphics 620. My main monitor I am trying to connect through DP is Samsung LCF27f398FWUXEN. The monitor and the DP cable works fine on my desktop. Secondary monitor, also connected to the dock, but through a VGA cable is a BenQ GL260. Display Ports on the dock don't work. When I plug the cable in, the other screen goes dark (sometimes for too long), and then there is still no new monitor detected. Seems like the monitor detects the input, at least for short time. Also, I have seen in Fedora Display Settings the monitor pop out for a short time after connecting and then disappear. If I boot with DP cable already connected, there is no input on the monitor. And when I log in, the secondary monitor goes black in a similar way as when the DP cable gets connected. 2. 5.7.12-200 3. It worked 4 months ago. I have not since tried to use Display Ports until now. I don't know what version it was. 4. Plug in a DP cable into the ThinkPad Thunderbolt 3 Dock or boot up with the cable connected. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: warning: /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/kernel-5.8.0-1.fc33.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY Fedora - Rawhide - Developmental packages for the next Fedora release GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64 (0x12C944D0) is already installed. The GPG keys listed for the "Fedora - Rawhide - Developmental packages for the next Fedora release" repository are already installed but they are not correct for this package. 6. Are you running any modules that not shipped with directly Fedora's kernel?: Not at the moment.
(In reply to Mark Menzynski from comment #0) > Created attachment 1711722 [details] > dmesg is a log with kernel parameters log_buf_len=50M drm.debug=0x116, state > is an output of /sys/kernel/debug/dri/0/state after booting up with only VGA > and DP cables connected > > 1. > I use a ThinkPad Thunderbolt 3 Dock with a ThinkPad T580, i7-8650U, UHD > Graphics 620. My main monitor I am trying to connect through DP is Samsung > LCF27f398FWUXEN. The monitor and the DP cable works fine on my desktop. > Secondary monitor, also connected to the dock, but through a VGA cable is a > BenQ GL260. > Display Ports on the dock don't work. When I plug the cable in, the other > screen goes dark (sometimes for too long), and then there is still no new > monitor detected. Seems like the monitor detects the input, at least for > short time. Also, I have seen in Fedora Display Settings the monitor pop out > for a short time after connecting and then disappear. If I boot with DP > cable already connected, there is no input on the monitor. And when I log > in, the secondary monitor goes black in a similar way as when the DP cable > gets connected. > > 2. > 5.7.12-200 > > 3. > It worked 4 months ago. I have not since tried to use Display Ports until > now. I don't know what version it was. > > 4. > Plug in a DP cable into the ThinkPad Thunderbolt 3 Dock or boot up with the > cable connected. > > 5. Does this problem occur with the latest Rawhide kernel? To install the > Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by > ``sudo dnf update --enablerepo=rawhide kernel``: > warning: > /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/kernel-5.8.0-1.fc33.x86_64. > rpm: Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY > Fedora - Rawhide - Developmental packages for the next Fedora release > GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64 (0x12C944D0) > is already installed. > The GPG keys listed for the "Fedora - Rawhide - Developmental packages for > the next Fedora release" repository are already installed but they are not > correct for this package. heh, tried these instructions in a container and fedora-repos-rawhide definitely seems to be broken, since they specify the gpgkey for each repository using $releasever instead of hardcoding it to rawhide, which because you're not on rawhide evaluates to 32 - causing it top try to verify the packages signed with the rawhide gpg key against the f32 gpg key, which of course fails. I'll go make a merge request on pagure to fix this. Anyway, workaround: add --nogpgcheck to the dnf update command and try again. Let me know if a rawhide kernel actually ends up fixing this, in the mean time I'm going to take a closer look at the dmesg you linked here and see if I can come up with any ideas/patches > > 6. Are you running any modules that not shipped with directly Fedora's > kernel?: > Not at the moment.
OK - squinted very hard at your log for a while and I've noticed a couple of things * The hub never reports more then one monitor being connected: [ 3.634388] [drm:drm_dp_send_link_address [drm_kms_helper]] link address reply: 4 [ 3.634394] [drm:drm_dp_send_link_address [drm_kms_helper]] port 0: input 1, pdt: 1, pn: 0, dpcd_rev: 00, mcs: 1, ddps: 1, ldps 0, sdp 0/0 [ 3.634399] [drm:drm_dp_send_link_address [drm_kms_helper]] port 1: input 0, pdt: 0, pn: 1, dpcd_rev: 00, mcs: 0, ddps: 0, ldps 0, sdp 0/0 [ 3.634404] [drm:drm_dp_send_link_address [drm_kms_helper]] port 2: input 0, pdt: 0, pn: 2, dpcd_rev: 00, mcs: 0, ddps: 0, ldps 0, sdp 0/0 [ 3.634409] [drm:drm_dp_send_link_address [drm_kms_helper]] port 3: input 0, pdt: 4, pn: 3, dpcd_rev: 00, mcs: 0, ddps: 1, ldps 1, sdp 1/1 (ldps = legacy device plug status, ddps = displayport device plug status, the only two ports that seem to be connected are the input port (which is expected, that's your laptop) and the VGA port. I remember you mentioning to me that you weren't sure if this was an issue with the dock, and I'm starting to become a bit suspicious the issue is something hardware related as well. I've got a couple of ideas for us to try: * You have probably already tried this but just to be sure: try using a different displayport on the dock * Try the rawhide kernel with the instructions I suggested, although I expect it might not fix it * Let's get another log exactly like the one you posted here, but instead let's try a couple different scenarios here: * Boot up with only the VGA monitor connected to the dock, then connect the DP connector to the hub after booting, wait a little bit, then grab me the dmesg in the same manner you did before * Boot up with only the DP monitor connected to the dock, and do the same thing but with the VGA adapter this time
(In reply to Lyude from comment #2) > * You have probably already tried this but just to be sure: try using a > different displayport on the dock Yes, I tried, and now again. > * Try the rawhide kernel with the instructions I suggested, although I > expect it might not fix it Nothing changed with the rawhide kernel. > * Let's get another log exactly like the one you posted here, but instead > let's try a couple different scenarios here: > > * Boot up with only the VGA monitor connected to the dock, then connect > the DP connector to the hub after booting, wait a little bit, then grab me > the dmesg in the same manner you did before > * Boot up with only the DP monitor connected to the dock, and do the same > thing but with the VGA adapter this time So with only VGA connected, I realized that one of the patterns is now recurrent. If I only boot with VGA, grub is okay, and until I log in into my user account. At that point, screen goes black, and it probably goes into a suspend mode, I think. The power button on a dock is slowly blinking, in a breathing way. Now I need to press the power button to bring it out of the suspend mode. Now power button is glowing, which means the system is running. But screen is still black. What I need to do now to get an image on a screen is 1. reconnect VGA, 2. connect a new working display connection. I will provide an attachment with few of the scenarios with logs right after sending this. About the DP scenario, could you please elaborate more? I could keep VGA connected screen plugged in to set up the kernel parameters, disconnect the monitor, confirm changes, and at some point connect back the secondary monitor. But I need to know when. I could probably enter the decryption password and log in to the user account without any image on a screen.
Created attachment 1712338 [details] dmesg#2 of new scenarios Booting with only VGA, after screen going black when loggin in, returning from suspend mode by pressing power button - vga-black-hdmi is after returning from suspend mode connecting a HDMI - vga-black-vga-replug is after returning from suspend mode, disconnecting the VGA and connecting it back - vga-black-vga-replug-dp is after returning from suspend mode, disconnecting VGA and connecting it back, then connecting the DP
(In reply to Mark Menzynski from comment #3) > (In reply to Lyude from comment #2) > > * You have probably already tried this but just to be sure: try using a > > different displayport on the dock > Yes, I tried, and now again. > > > * Try the rawhide kernel with the instructions I suggested, although I > > expect it might not fix it > Nothing changed with the rawhide kernel. > > > * Let's get another log exactly like the one you posted here, but instead > > let's try a couple different scenarios here: > > > > * Boot up with only the VGA monitor connected to the dock, then connect > > the DP connector to the hub after booting, wait a little bit, then grab me > > the dmesg in the same manner you did before > > * Boot up with only the DP monitor connected to the dock, and do the same > > thing but with the VGA adapter this time > > So with only VGA connected, I realized that one of the patterns is now > recurrent. > If I only boot with VGA, grub is okay, and until I log in into my user > account. At that point, screen goes black, and it probably goes into a > suspend mode, I think. The power button on a dock is slowly blinking, in a > breathing way. Now I need to press the power button to bring it out of the > suspend mode. Now power button is glowing, which means the system is > running. But screen is still black. What I need to do now to get an image on > a screen is 1. reconnect VGA, 2. connect a new working display connection. I > will provide an attachment with few of the scenarios with logs right after > sending this. OK-that's useful to know. it seemed like from the logs that you sent me in the past that you've been booting your system up with the lid closed. So it sounds like between boot and when you log into your user session it's seeing the VGA display, then when you log in it suddenly doesn't detect it. My guess is that it's getting reprobed just because of gnome-shell starting up. I'll see if I can figure out anything from the logs that you've got me, but definitely don't be surprised if I need to ask for more. > > About the DP scenario, could you please elaborate more? I could keep VGA > connected screen plugged in to set up the kernel parameters, disconnect the > monitor, confirm changes, and at some point connect back the secondary > monitor. But I need to know when. I could probably enter the decryption > password and log in to the user account without any image on a screen. So: first off for all the scenarios I think it would make things easier if you kept your laptop's screen open, so it doesn't go into suspend immediately if it stops detecting the VGA display. Coincidentally, the logs you gave me actually pointed out another bug that seems to be happening here where gnome-shell doesn't restore the display mode properly on resume (I'll add a link to the upstream bug I filed for this in a second). I'm pretty confident if we can fix the issue with it losing the display after logging in, the laptop should also stop going into suspend after you've logged in. As for when to plug in the displays: I would just plug each combination of displays I gave before you turn on the laptop, add the kernel command line parameters I gave you when you're in grub (drm.debug=0x116 log_buf_len=50M), and then leave them plugged in until you log in and the screen goes black (if that's not possible, unplugging them shortly after you log in should be fine). Then, grab the dmesg afterwards.
Oh also - just setting NEEDINFO here until I get the new logs, but I'll look at what I've gotten from you in the mean time.
Created attachment 1714073 [details] dmesg#3 DP-then-VGA - Booted with DP connected and laptop lid open. After logging in connecting in VGA and saving logs VGA-then-DP - Same but booting with VGA, and connecting DP after
(In reply to Mark Menzynski from comment #7) > Created attachment 1714073 [details] > dmesg#3 > > DP-then-VGA - Booted with DP connected and laptop lid open. After logging in > connecting in VGA and saving logs > VGA-then-DP - Same but booting with VGA, and connecting DP after Thanks - I'll try to take a look at this this week
I have moved into an office. And here DisplayPorts on NEC E231W monitor work just fine.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.