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

AMD General

Hi:

    Thanks for your feedback.

> -----Original Message-----
> From: Daniel Stone <[email protected]>
> Sent: Thursday, August 13, 2026 04:36
> To: Zuo, Jerry <[email protected]>
> Cc: Derek Foreman <[email protected]>; amd-
> [email protected]; [email protected]; Wentland, Harry
> <[email protected]>; Tomasz Pakuła
> <[email protected]>
> Subject: Re: [PATCH v3 4/4] drm/amd/display: Add HDMI ALLM support
>
> Hi there,
>
> On Wed, 12 Aug 2026 at 01:43, Zuo, Jerry <[email protected]> wrote:
> > Below two scenarios belong to static/modeset ALLM
>
> Thanks a lot for these clarifications.
>
> > #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.
>
> This is the interesting part.
>
> > > > 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.
>
> VRR_ENABLED is a completely separate bit though.

Yes, VRR_ENABLED is its own dedicated property that maps 1:1 to VRR_EN.
There are two independent triggers in the patch, and only one of them is a
policy decision:
1. During Gaming-VRR the sink is expected to be in its low-latency mode
regardless of the bit — a compositor property that cleared ALLM here
would be both non-compliant and ineffective. This part therefore has to
stay in the driver.
2. content_type == Game -> ALLM. This one I agree is a policy decision, and
it's the subjective trade-off you're describing.
(Game with ALLM_Mode=0 is a valid combination)

>
> > 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 really think the burden of proof for implicit semantics in KMS should be the
> other way around: do we unavoidably need this, or is there (currently) no
> other option at all?
>
> I don't think ALLM falls into this basket at all. It's nice to have for gaming (and
> mandatory for gaming VRR mode), but there are plenty of different scenarios
> where having it on or off is a legitimate choice. For instance, should desktops
> imply ALLM because they aren't going to smooth your text into oblivion, or
> should they not because you're probably not going to read text on a 49"
> display? Should all games imply ALLM because you need the response time,
> or are you maybe playing Myst on your TV?
>
> I understand the attraction behind 'we can just stuff this in the kernel and it
> will dtrt', but hey, that's what people thought about Broadcast RGB at the
> time. Or colour model/subsampling selection on the wire. Or or or ...
>

Yes I agreed. content_type -> ALLM doesn't clear that bar, and I'll drop it.

I'll submit another v4 based on below soon:
1. Keep only the case we have no choice about: set ALLM_Mode=1 when
    Gaming-VRR is active (VRR_EN=1) and the sink advertises ALLM, per spec 7.6.6.
    This stays in the driver.
2. Remove the content_type == Game heuristic from both the modeset and the
     freesync paths. No implicit ALLM derived from content type.
3. No new implicit semantics, and no DRM-helper "default" either. If a
    concrete need for explicit ALLM control shows up, it should be a proper
    (ideally generic) property with a real userspace user driving it, not
    something the kernel infers.

Regards,
Jerry

> Cheers,
> Daniel