Hi Maxime, Thank you for the feedback. You're right - showing the driver usage is important to validate the API design before merging framework changes.
I'm preparing follow-up patches to demonstrate how this would be used in practice. Here's the plan: 1. DRM driver side: Show where to call drm_connector_hdmi_audio_crtc_notify() in the CRTC enable/disable paths (using i915 as an example) 2. Audio codec side: Show how an audio codec driver would implement the crtc_state_change callback (using HDA HDMI as an example) I'll send these as a small series (framework patch + driver usage examples) for your review. The examples will show: - How i915 would notify audio when a CRTC is disabled while the connector remains physically connected (e.g., user switches to "internal display only") - How the HDA HDMI codec would handle this notification to prevent silent audio breakage Would you prefer I send the full series now, or would you like to see the example patches first for API design review? Best regards, Wang Dicheng At 2026-06-04 21:22:39, "Maxime Ripard" <[email protected]> wrote: >Hi, > >On Wed, May 27, 2026 at 04:53:29PM +0800, [email protected] wrote: >> From: wangdicheng <[email protected]> >> >> The DRM HDMI audio helper framework notifies the audio codec about >> physical connection changes via drm_connector_hdmi_audio_plugged_notify(), >> but has no mechanism to notify when the CRTC state changes while the >> connector remains physically connected. >> >> This is a real problem on platforms with DP/HDMI audio. When a CRTC is >> disabled while the sink remains connected (e.g. user switches to >> "internal display only" mode but still wants audio from the external >> monitor), the audio path silently breaks because: >> >> 1. The video stream is disabled, so there are no blanking intervals >> for audio Secondary Data Packets (SDP) to be transported. >> >> 2. The audio codec still believes the jack is present because >> plugged_notify() was not called (the connector is still physically >> connected). >> >> 3. Userspace (PulseAudio/PipeWire) continues routing audio to the >> external display, but no sound is actually output. >> >> Without a framework-level notification, vendors who need to support >> "audio output to external display while CRTC is inactive" are forced >> to scatter condition checks across CRTC disable, encoder disable, >> suspend, and resume paths. This pattern is fragile: any change in >> the display pipeline can break the audio path, and the same condition >> ("connector connected but CRTC inactive, and audio is in use") must >> be duplicated in multiple locations. >> >> The root cause is architectural: the audio codec has no visibility >> into CRTC state changes, so there is no clean way to implement >> policies like: >> >> - Mute audio output when CRTC is disabled (instead of silent breakage) >> - Keep the video stream alive for audio transport >> - Switch to DP Audio Only mode (hardware-supported on some platforms, >> e.g. Intel TRANS_DP_AUDIO_ONLY, but never used in i915 driver) >> >> The HDA HDMI silent stream / KAE mechanism partially addresses this on >> Intel platforms, but it operates only on the audio codec side and does >> not coordinate with the DRM side. It also cannot work on platforms >> without HDA codec support (e.g. ASoC-based designs). >> >> Add an optional callback crtc_state_change() to >> drm_connector_hdmi_audio_funcs, and a corresponding notification >> function drm_connector_hdmi_audio_crtc_notify(). DRM drivers should >> call this when the CRTC state changes on a connector with audio >> capability, allowing audio codec implementations to react to display >> pipeline state changes rather than only physical connection changes. >> >> This provides a framework-level mechanism to implement "audio without >> active display" policies cleanly, instead of scattering condition >> checks across the display pipeline. >> >> Signed-off-by: wangdicheng <[email protected]> > >I'm not saying this is right or wrong, but I'd like to see what it looks >like from a driver point of view before merging anything in the >framework. > >Maxime
