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
