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. > 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 ... Cheers, Daniel
