<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - dc=1 kernels somehow trigger a disconnect of an lg ultrawide monitor during DP link training while attempting a wakeup"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=106529#c1">Comment # 1</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - dc=1 kernels somehow trigger a disconnect of an lg ultrawide monitor during DP link training while attempting a wakeup"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=106529">bug 106529</a>
              from <span class="vcard"><a class="email" href="mailto:mariusz.g.mazur@gmail.com" title="Mariusz Mazur <mariusz.g.mazur@gmail.com>"> <span class="fn">Mariusz Mazur</span></a>
</span></b>
        <pre>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: <a href="https://patchwork.freedesktop.org/patch/209464/">https://patchwork.freedesktop.org/patch/209464/</a> 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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>