RE: [PATCH v3 4/4] drm/amd/display: Add HDMI ALLM support

AMD General

> -----Original Message-----
> From: Daniel Stone <[email protected]>
> Sent: Tuesday, August 11, 2026 11:24
> To: Derek Foreman <[email protected]>
> Cc: Zuo, Jerry <[email protected]>; [email protected]; dri-
> [email protected]; Wentland, Harry <[email protected]>;
> Tomasz Pakuła <[email protected]>
> Subject: Re: [PATCH v3 4/4] drm/amd/display: Add HDMI ALLM support
>
> [You don't often get email from [email protected]. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi,
>
> On Tue, 11 Aug 2026 at 14:54, Derek Foreman
> <[email protected]> wrote:
> > On 8/10/26 7:39 PM, Fangzhi Zuo wrote:
> > > +             /*
> > > +              * Enable HDMI ALLM (Auto Low-Latency Mode) when the sink
> > > +              * advertises ALLM in the SCDS and the content type is Game.
> > > +              * Setting content-type = Game is how userspace requests the
> > > +              * Sink's low-latency mode (HDMI GCTS HF1-56).
> > > +              */
>

Below two scenarios belong to static/modeset ALLM

#1
> Is it mandatory for the source to set ALLM when the sink advertises ALLM
> support, and content-type == game?
Allowable ALLM == 1, but not mandatory, means ALLM can be set to 0
From spec 10.11, P456, 582, 583

#2
> Is it allowable for the source to set ALLM when the sink advertises ALLM
> support, and content-type != game?
Allowable ALLM == 1
From spec 10.11, P456, 582

Above two scenarios are simply subjective policies, not defined in the spec.

>
> > > +     /*
> > > +      * HDMI ALLM: transmit the HF-VSIF with ALLM_Mode=1 when the
> sink
> > > +      * advertises ALLM in the SCDS and either the content type is Game
> > > +      * (HF1-56) or Gaming-VRR is active (VRR_EN=1, HF1-58 step 8.3.1).
> > > +      * HDMI 2.1 7.6.6.
> > > +      */

#3. Gaming-VRR
> Is it mandatory for the source to set ALLM when the sink advertises ALLM
> support, and game-VRR is active?
Mandatory to set ALLM == 1
From spec 7.6.6, P240
It is spec mandatory, and we follow it.

#4. QMS-VRR
> Is it allowable for the source to set ALLM when the sink advertises ALLM
> support, and non-game-VRR is active?
It is QMS-VRR, mandatory to set ALLM == 0
From spec 10.11, P456, 240
It is spec mandatory when enabling QMS-VRR, but it is not yet implemented in current change.

>
> > Tying this to Gaming-VRR seems potentially surprising. Gaming-VRR
> > doesn't mean we're playing a game. We might be using it to play back
> > judder free video (where we'd like ALLM off to preserve the sink's
> > image enhancement), or we might be at the desktop.
> >
> > I'd imagine some users would still want their sink to use all the
> > image enhancements they saw in the showroom even when playing a game,
> > so I'm not sure any kind of "auto" decision making in the kernel makes
> > sense at all, even based on content type. It's a very subjective trade-off.
> >
> > To me, this seems like something a compositor would want control of
> > with a simple boolean property.

ALLM_Mode is a protocol-level HF-VSIF bit; like VRR_EN, the driver derives
it from existing compositor-set KMS state rather than exposing a new bit.
The Gaming-VRR case #3 is not policy at all. 7.6.6 mandates ALLM_Mode=1
when VRR_EN=1 and the sink advertise ALLM, so it must live in the driver.

The only discretionary piece is content_type = Game ⇒ ALLM (#1, #2),
which CTA-861's latency-minimization recommendation for Game IT content
makes a reasonable default (Appendix G lists it as allowable).
To avoid per-driver divergence, that default could live in a DRM helper,
with room to add an explicit override property later if a concrete need arises.
It can be planned in the future.

>
> I strongly agree. I really don't want to see more magic implicit semantics
> unless they're completely necessary for some reason.
>
> Someone passed on second-hand that one of the reasons to do this was to
> make it easier to support X11 - however, if X11 needs better ALLM control,
> then it can be exposed as a connector property via RandR, just like content-
> type.
>
> Cheers,
> Daniel