Re: [PATCH v3 16/19] drm/amd/display: Add parameter to control ALLM behavior

["Tomasz Pakuła" <tomasz.pakula.oficjalny@gmail.com>]

On Tue, 2026-02-10 at 14:17 -0500, Alex Deucher wrote:
> On Tue, Feb 10, 2026 at 1:44 PM Tomasz Pakuła
> <tomasz.pakula.oficjalny@gmail.com> wrote:
> > 
> > On Fri, 2026-02-06 at 17:04 -0500, Alex Deucher wrote:
> > > 
> > > Also, maybe a per connector kms property would be preferable.  Then
> > > you could change it per display.
> > > 
> > > Alex
> > 
> > I've dealt with all Harry's comments but wanted to make sure I
> > understand properly. Do you mean, that the two settings should be a
> > connector property like VRR_ENABLED? I understand the intent and I think
> > in some time, it would be best to have these exposed in compositor
> > settings but how would a user control this until then?
> > 
> > Would it suffice to fire IOCTLs from a third-party tool like LACT where
> > support for this could be added in a short time?
> > 
> > I made it a module property in the first place, because I thought such
> > settings are pretty set-and-forget and module properties are just easy
> > to set :)
> > 
> > Still, I think the defaults are sane. If I have to spend some more time
> > to get the connector properties working, I could send the patches with
> > the module properties ripped out for now.
> 
> My understanding is that these are something the compositor would like
> to manage.  I'd like to avoid adding module parameters if we can help
> it because they usually cause more trouble than they help due to
> unforeseen interactions with other features or "conventional wisdom"
> blindly followed which leads to a bad user experience.
> 
> Alex

Sure!

I'll remove the parameters for now and send v4 to get some feedback on
the cleanups and then I'll figure out the KMS properties. You're right,
leaving that in would surely lead to issues and then people lamenting
their removals..

Thanks for all the comments and all your work!

Tomasz