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

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).
> > +              */

Is it mandatory for the source to set ALLM when the sink advertises
ALLM support, and content-type == game?

Is it allowable for the source to set ALLM when the sink advertises
ALLM support, and content-type != game?

> > +     /*
> > +      * 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.
> > +      */

Is it mandatory for the source to set ALLM when the sink advertises
ALLM support, and game-VRR is active?

Is it allowable for the source to set ALLM when the sink advertises
ALLM support, and non-game-VRR is active?

> 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.

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