Re: [PATCH v2 17/27] drm/connector: Add "Media" VRR display mode for QMS

[Nicolas Frattaroli]

On Thursday, 12 November 2026 07:18:21 Central European Standard Time Vidith Madhu wrote:
> 
> On Thu, 5 Nov 2026, Nicolas Frattaroli wrote:
> 
> > HDMI includes a feature called "Quick Media Switching", or QMS for
> > short, which builds upon the existing VRR to allow for quick switching
> > between a select few common frame rates.
> > 
> > Add a new VRR display mode, "VRR_DISPLAY_MODE_MEDIA", to the
> > vrr_display_mode connector property, in order to expose support for
> > this.
> > 
> > Additionally, add a boolean flag to the connector's HDMI sub-struct with
> > which source-side support for QMS can be indicated, as well as the QMS
> > tfr byte to the HDMI state sub-struct.
> > 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@xxxxxxxxxxxxx>
> > ---
> >  drivers/gpu/drm/drm_connector.c |  6 ++++++
> >  include/drm/drm_connector.h     | 14 ++++++++++++++
> >  2 files changed, 20 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 21222214a843..f7d619926e2d 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1456,6 +1456,7 @@ DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
> >  static const struct drm_prop_enum_list drm_vrr_mode_enum_list[] = {
> >  	{ VRR_DISPLAY_MODE_GAME,   "Game" },
> >  	{ VRR_DISPLAY_MODE_OFF,    "Off" },
> > +	{ VRR_DISPLAY_MODE_MEDIA,  "Media" },
> >  };
> >  DRM_ENUM_NAME_FN(drm_get_vrr_mode_name, drm_vrr_mode_enum_list)
> >  
> > @@ -2593,6 +2594,11 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
> >   *	    - Game - set display to game mode if display supports it,
> >   *	      regardless of CRTC state
> >   *	    - Off - set display to VRR disabled mode, regardless of CRTC state
> > + *	    - Media - a "media" VRR mode that only supports a select number of
> > + *	      common media refresh rates as fixed targets, but does so with
> > + *	      possibly better display-side processing. In the HDMI display
> > + *	      protocol, this is QMS (Quick Media Switching), though the mode
> > + *	      enum itself is vendor-agnostic
> >   *
> >   * VRR Limiter/Target Properties
> >   * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 4801bb2769e1..41f272afbb1e 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -829,6 +829,8 @@ enum vrr_display_mode {
> >  	VRR_DISPLAY_MODE_GAME = 0,
> >  	/** @VRR_DISPLAY_MODE_OFF: Turn off VRR on the display */
> >  	VRR_DISPLAY_MODE_OFF,
> > +	/** @VRR_DISPLAY_MODE_MEDIA: Protocol-agnostic fixed rate media mode */
> > +	VRR_DISPLAY_MODE_MEDIA,
> >  	/** @VRR_DISPLAY_MODE_COUNT: Sentinel, not a valid mode, keep last */
> >  	VRR_DISPLAY_MODE_COUNT
> >  };
> > @@ -1241,6 +1243,12 @@ struct drm_connector_hdmi_state {
> >  	 * deliberately not requested by the helper.
> >  	 */
> >  	bool scrambler_needed;
> > +
> > +	/**
> > +	 * @qms_tfr_byte: Target frame rate byte for HDMI QMS, or 0 if QMS is
> > +	 * not in use.
> > +	 */
> > +	u8 qms_tfr_byte;
> >  };
> >  
> >  /**
> > @@ -2270,6 +2278,12 @@ struct drm_connector_hdmi {
> >  	 */
> >  	bool scrambler_enabled;
> >  
> > +	/**
> > +	 * @qms_supported: Whether the connector supports HDMI Quick Media
> > +	 * Switching (QMS) on the source side, irrespective of display support.
> > +	 */
> > +	bool qms_supported;
> I'm not really understanding why a source-side capability is being 
> captured at the connector level. The way I envisioned this is that
> source-side Media-VRR support can be determined by whether the driver
> attaches the CRTC frame limit properties. The ability to maintain an
> arbitrary fixed refresh rate (implied by attaching the properties) should
> be the only QMS-specific requirement the source needs to support.

Is this the case? I have little information about the QMS specification
or the hardware implementations, so I was basically hedging for an odd
case where an HDMI implementation is abstracted enough to where we can
get it to send VTEM EMP packets through some interface, but not with
QMS TFR bytes.

If that's something so far out there it probably won't ever exist, I'm
happy to remove this and make QMS checks just a check for the limiter
properties.

Kind regards,
Nicolas Frattaroli

> 
> Thanks,
> Vidith 
> > +
> >  	/**
> >  	 * @scdc_work: Work item currently used to monitor sink-side scrambling
> >  	 * status and retry setup if the sink resets it.
> > 
>