<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][BAT] igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)" href="https://bugs.freedesktop.org/show_bug.cgi?id=111045#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [CI][BAT] igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)" href="https://bugs.freedesktop.org/show_bug.cgi?id=111045">bug 111045</a> from <a class="email" href="mailto:imre.deak@intel.com" title="Imre Deak <imre.deak@intel.com>"> Imre Deak</a> <pre>(In reply to Imre Deak from <a href="show_bug.cgi?id=111045#c15">comment #15</a>) > (In reply to emersion from <a href="show_bug.cgi?id=111045#c14">comment #14</a>) > > (In reply to Imre Deak from <a href="show_bug.cgi?id=111045#c6">comment #6</a>) > > > There could be a chamelium config issue wrt. HDMI, since there is no HDMI > > > sinks connected (even the USBC->HDMI dongle will show up as DP), but the > > > HDMI chamelium subtests are not skipped as they should be. > > > > I think the configuration is fine. I routinely run HDMI tests on my DP port > > with lspcon, and configuring .igtrc to map the DUT DP output to the > > Chamelium HDMI input works. > > With DP++ connectors that should work (with a DP++->HDMI dongle), but here > we're talking about a USB-C connector which does not have HDMI output > support. The driver doesn't even register an HDMI output for these connector. > > You can connect a USB-C connector to an HDMI input via a TypeC-DP-alt->HDMI > dongle, but that is still a DP connector from the driver's and the igt > test's POV, and so all the Chamelium HDMI subtests should be skipped - which > is what I talked about above. Ah, now I got how the chamelium HDMI subtests work, they also allow a DP source connected to an HDMI sink. So you are right the HDMI subtests should also be run for DP-alt connectors, but they have the same problem as discussed below about having a mode enabled all the time while toggling HPD. > > > > > > However probably all the DP kms_chamelium tests will fail expectedly on > > > DP-alt outputs. > > > > Can you elaborate? I'm not sure I understand. > > 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. > > > > The exceptions could be kms_chamelium subtests where the > > > subtest properly handles hotplug events: enables/disables the output > > > according to the connect/disconnect hotplug event it receives. That's not > > > the case atm with most of the kms_chamelium subtests. > > > > Why is this needed? If a user plugs a USB-C to HDMI dongle, the DRM client > > should see a hotplug event even if the output hasn't been enabled yet, right? > > 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. > > > Some tests currently assert HPD on the Chamelium side and expect a hotplug. > > Is this supposed not to work with DP-ext? > > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>