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
