On 2026-08-13 06:29, Daniel Stone wrote:
> On Tue, 11 Aug 2026 at 18:42, Harry Wentland <[email protected]> wrote:
>> On 2026-08-11 11:23, Daniel Stone wrote:
>>> On Tue, 11 Aug 2026 at 14:54, Derek Foreman <[email protected]>
>>> wrote:
>>>> 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.
>
> Poor old Weston, no longer canonical ... !
>
Apologies, I realized Weston used it after sending the email.
But it also doesn't do it dynamically but with a config file,
if I understand it right. So, it exercises the option but is
not super useful to judge how a dynamic/general purpose compositor
would behave.
> Seriously though, I see the point, I'm just really wary about the
> kernel trying to be too cute about policy. If you want to use Weston
> as a vehicle for an ALLM property, we'll happily give you one
> tomorrow. It would be static as is all our current output
> configuration, but we could also type up something easily enough to
> implement the content-type hint protocol for dynamic use, with a user
> configuration of 'enable ALLM if there are no games on screen'.
>
No, thanks for pushing on the policy. These specs (HDMI, VESA) generally
don't think about SW architecture and treat a source as a monolithic
beast controlled by an IHV, which it is not.
Harry
> Cheers,
> Daniel
