On Wednesday, May 21st, 2025 at 21:18, Harry Wentland <harry.wentl...@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.h...@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.
