<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [CI][BAT] igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=111045#c24">Comment # 24</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [CI][BAT] igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=111045">bug 111045</a>
              from <span class="vcard"><a class="email" href="mailto:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> <span class="fn">Imre Deak</span></a>
</span></b>
        <pre>(In reply to emersion from <a href="show_bug.cgi?id=111045#c22">comment #22</a>)
<span class="quote">> (In reply to Imre Deak from <a href="show_bug.cgi?id=111045#c15">comment #15</a>)
> > If unplugging a DP-alt display while there is an active modeset on it, and
> > then replugging the DP-alt display, the HW/FW/driver won't signal the
> > corresponding plug-in hotplug event until the mode is disabled.

> Hmm, I see.

> > The failing tests do this:
> > 
> > - <have the output enabled>
> > - unplug the display, keeping the output enabled
> > - wait/poll for the disconnect status -> success
> > - replug the display, while the output is still enabled
> > - wait/poll for the connect status -> fail
> > 
> > This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> > dongle), as I described above. 

> Thanks for the explanation!

> > If there wouldn't be any mode enabled for the whole duration of the
> > sequence, or the client would enable/disable the mode according to the
> > output's connected/disconnected status, then all the hotplug uevents,
> > polling would work as the test expects.

> I'll try to send a patch to do this.</span >

Ok, thanks a lot for looking into that. Btw, are you planning to add new
subtests that work according to the above (instead of modifying the existing
ones) and black list somehow the existing ones (at least for now) for DP-alt
connectors? That would be ideal, since we should still keep the existing ones
as-is to retain the coverage for all that scenarios.

Running the old ones (with reduced timeout) on DP-alt would be still good to
check for any kernel breakage with enabled outputs, but atm that slows things
down a lot since each subtest incurs a 20sec timeout on DP-alt...</pre>
        </div>
      </p>


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

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>