<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#c15">Comment # 15</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 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. > > > 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>