Comment # 1
on bug 106529
from Mariusz Mazur
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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
