[Bug 106529] Kernels 4.16+ confuses KDE wrt what the primary display is when waking up multiple displays
https://bugs.freedesktop.org/show_bug.cgi?id=106529
Bug ID: 106529 Summary: Kernels 4.16+ confuses KDE wrt what the primary display is when waking up multiple displays Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mariusz.g.mazur@gmail.com
Created attachment 139577 --> https://bugs.freedesktop.org/attachment.cgi?id=139577&action=edit ubuntu's 4.15 dmesg with amdgpu.dc_log=1
It appears that the display-handling code in 4.15+ (including 4.17-rc5) marks any display not fully woken up as disconnected or something to that effect. So when I have multiple monitors and they get woken up from sleep (doesn't matter whether the computer was suspended or just idle for a long period), and my primary display wakes up slower than the any of the other displays (and it does), then for a few hundred ms KDE tries to change the primary display to the one that first woke up (I'm guessing it thinks that's the only one available), then changes its mind a bit later, when all displays wake up.
End result looks like crap and is not usable, since all my windows get displaced. Here's how it looks like in practice:
Setup: Radeon RX 560 Primary display: bottom right, displayport, on Secondary display 1: left, hdmi, on Secondary display 2: top right, dvi, off
Video of how it used to work, using 4.4.15: https://www.youtube.com/watch?v=h7nMYbm5ZxU Note how even though the left (secondary) display wakes up first, both instantly display their proper desktops.
Video of how it works with ubuntu 18.04's default 4.15 kernel/4.16.7/4.17-rc5: https://www.youtube.com/watch?v=VdVFNXPszSI Note how when the left (secondary) display wakes up first, KDE decides that this is probably the only display available, so tries to switch the primary desktop to it, then a split second later the bottom right wakes up and KDE knows *that* should be the primary according to the config, so it switches back.
Attached is dmesg from ubuntu's 4.15 with dc_log=1. I put the computer to sleep, then wake it up and get the behavior like in the video.
https://bugs.freedesktop.org/show_bug.cgi?id=106529
Mariusz Mazur mariusz.g.mazur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Kernels 4.16+ confuses KDE |Kernels 4.16+ confuse KDE |wrt what the primary |wrt what the primary |display is when waking up |display is when waking up |multiple displays |multiple displays
https://bugs.freedesktop.org/show_bug.cgi?id=106529
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #139577|text/x-log |text/plain mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=106529
Mariusz Mazur mariusz.g.mazur@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Kernels 4.16+ confuse KDE |dc=1 kernels somehow |wrt what the primary |trigger a disconnect of an |display is when waking up |lg ultrawide monitor during |multiple displays |DP link training while | |attempting a wakeup
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #1 from Mariusz Mazur mariusz.g.mazur@gmail.com --- I've tried the same thing with only the DP ultrawide monitor connected and got the same issue. dc logs, reading code and some kernel tracers (ftrace) on DC link training code basically tell me that the important part is this:
21:23:16 [drm] [LKTN] [DP][ConnIdx:0] RBRx4 pass VS=2, PE=1^ 21:23:16 [drm] link=0, dc_sink_in= (null) is now Disconnected 21:23:18 [drm] [LKTN] [DP][ConnIdx:0] HBRx4 pass VS=1, PE=0^ 21:23:18 [drm] link=0, dc_sink_in=00000000dbbee48e is now Connected 21:23:18 [drm] [LKTN] [DP][ConnIdx:0] RBRx4 pass VS=1, PE=1^
Whatever's going on with the first attempt at link training, it ends up with the monitor disconnecting (not sure if deliberately or by causing some error in the monitor; didn't dive deep enough into the code).
Pre-DC codepaths did not have an issue like this at all until Michel Dänzer created this patch: https://patchwork.freedesktop.org/patch/209464/ for bug 105308 thereby introducing a problem with the same effects (DC monitor gets disconnected on wakeup, which on multi-display causes issues) via a quite different approach (a deliberate DRM_MODE_DPMS_OFF & ON). But that should be a separate bug, I think.
And since Michel's patch got applied to all the kernels, the effect is that on any up to date 4.15+ kernel the same issue shows up whether you're doing dc=1 or dc=0, while the actual code paths causing it are different. (Which made this a PITA to figure out.)
Anyway, since I know nothing about DP link training and how to fix code relating to it, I've just bought a DP->HDMI cable thus "fixing" my problem entirely (including the second issue of a 2s lag with DP audio).
Hopefully someone in the future, a future man so to speak, will fix this issue eventually. Cause currently DP support is quite bad, it seems.
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #2 from Michel Dänzer michel@daenzer.net --- (In reply to Mariusz Mazur from comment #1)
FWIW, that change should have no direct effect on whether the display is considered connected or disconnected. The only change is that when the driver is notified that a DP display is "disconnected" (which can also happen without a physical disconnection, e.g. if the display is turned off), it doesn't immediately turn off the GPU's DP source anymore, but waits until either userspace asks to turn it off, or it gets notified that a display is "connected" again. Both "disconnect" / "connect" hotplug events are sent to userspace before and after this change. I suspect that immediately turning off the DP source simply happened to delay sending the "disconnect" hotplug event to userspace enough to avoid the issue on your system.
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #3 from Mariusz Mazur mariusz.g.mazur@gmail.com --- dc=1 codepath has the problem occur 100% of the times the display wakes up (iirc).
dc=0 with your patch does not. It happens regularly, but not 100% of the times. Which I guess does indicate there's some timing issues involved.
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #4 from Alex Deucher alexdeucher@gmail.com --- I suspect it may have something to do with the pulse timing from the monitor. Long pulses are for connect/disconnect events and short pulses are a feedback mechanism for the monitor to the driver. I suspect the monitor is sending a short pulse that the driver is interpreting as a long pulse.
https://bugs.freedesktop.org/show_bug.cgi?id=106529
--- Comment #5 from Michel Dänzer michel@daenzer.net --- Maybe one thing we could do is delaying the sending of the disconnect hotplug event to userspace by some time (though at most until the next connect hotplug event).
https://bugs.freedesktop.org/show_bug.cgi?id=106529
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #6 from Martin Peres martin.peres@free.fr --- -- 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/386.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org