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

On 2026-08-11 11:23, Daniel Stone wrote:
> 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.
> 

Yes, though I wonder what's the point of the content_type property
then. It's another one of those properties that's defined and unused
by all canonical upstream compositors.

Harry

> 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