[PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline

[Simon Ser]

On Wednesday, May 21st, 2025 at 21:18, Harry Wentland <harry.wentland at amd.com> wrote:

> On 2025-05-20 16:13, Harry Wentland wrote:
> 
> > On 2025-05-19 19:43, Simon Ser wrote:
> > 
> > > On Sunday, May 18th, 2025 at 00:32, Xaver Hugl xaver.hugl at gmail.com wrote:
> > > 
> > > > > We can always make the property mutable on drivers that support it in
> > > > 
> > > > > the future, much like the zpos property. I think we should keep it
> > > > > immutable for now.
> > > > 
> > > > Sure, but I don't see any reason for immutability with an enum
> > > > property - it can just limit the possible values to what it supports,
> > > > and that can be only one value. Either way, it's not a big issue.
> > > 
> > > Immutability is a clear indication that a property has a fixed read-only
> > > value which can't be switched by user-space. That's also the pattern
> > > used everywhere in the KMS uAPI, so I think it's better to remain
> > > consistent here.
> > 
> > I was envisioning this to be a driver-caps thing, but I agree
> > if we make this mutable it can still serve that function but with
> > different/future HW possibly support other interpolation schemes.
> 
> Would changing this enum property from IMMUTABLE to MUTABLE
> in the future (for drivers that support multiple types) break
> any userspace that assumes IMMUTABLE?

I don't think it would, see the zpos property.