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