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

[Shankar, Uma]

> -----Original Message-----
> From: Simon Ser <contact at emersion.fr>
> Sent: Thursday, May 22, 2025 3:45 PM
> To: Harry Wentland <harry.wentland at amd.com>
> Cc: Xaver Hugl <xaver.hugl at gmail.com>; Alex Hung <alex.hung at amd.com>; dri-
> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org; wayland-
> devel at lists.freedesktop.org; leo.liu at amd.com; ville.syrjala at linux.intel.com;
> pekka.paalanen at collabora.com; mwen at igalia.com; jadahl at redhat.com;
> sebastian.wick at redhat.com; shashank.sharma at amd.com; agoins at nvidia.com;
> joshua at froggi.es; mdaenzer at redhat.com; aleixpol at kde.org;
> victoria at system76.com; daniel at ffwll.ch; Shankar, Uma
> <uma.shankar at intel.com>; quic_naseer at quicinc.com;
> quic_cbraga at quicinc.com; quic_abhinavk at quicinc.com; marcan at marcan.st;
> Liviu.Dudau at arm.com; sashamcintosh at google.com; Borah, Chaitanya Kumar
> <chaitanya.kumar.borah at intel.com>; louis.chauvet at bootlin.com
> Subject: Re: [PATCH V8 40/43] drm/colorop: Add 3D LUT support to color pipeline
> 
> 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.

I agree, should be ok as long as driver supports. Doesn't break any UAPI contract here.

Regards,
Uma Shankar