[PATCH i-g-t] tests/kms_properties: drop immutability checks

[Xaver Hugl]

Am Fr., 19. Juli 2024 um 13:57 Uhr schrieb Dmitry Baryshkov
<dmitry.baryshkov at linaro.org>:
>
> On Fri, 19 Jul 2024 at 14:55, Xaver Hugl <xaver.hugl at kde.org> wrote:
> >
> > Am Fr., 19. Juli 2024 um 12:10 Uhr schrieb Daniel Stone <daniel at fooishbar.org>:
> > >
> > > Hi,
> > >
> > > On Thu, 18 Jul 2024 at 11:01, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > > > On Wed, Jul 17, 2024 at 05:39:47PM +0300, Dmitry Baryshkov wrote:
> > > > > Following the discussion on IRC, it is actually an error to require that
> > > > > properties that can not be chaged are marked as immutable.
> > > > >
> > > > > First of all, it creates inconsistent uAPI. Some drivers might have an
> > > > > immutable property, while others will have it mutable. Yes, there are
> > > > > known examples for such behaviour (e.g. zpos), but they are clearly
> > > > > documented in this way.
> > > > >
> > > > > Second, by the nature of the flag, the DRM_MODE_PROP_IMMUTABLE defines
> > > > > more of the 'direction' of the property (whether it is set by the kernel
> > > > > or it is expected to be set by the userspace) rather than simply states
> > > > > that there is no way for the userspace to change the property.
> > > > >
> > > > > Drop the single-value-is-immutable tests.
> > > >
> > > > Makes sense, but we might drop some test coverage for the properties where
> > > > we _do_ want the single value to be immutable. Like zpos.
> > > >
> > > > So I think at least a cursory audit of existing properties would be good,
> > > > checking that the kerneldoc is accurate and then maybe limiting these
> > > > checks here to properties which are documented to have this behaviour?
> > > >
> > > > I know that's a bunch more work, but I fear if we just drop this we only
> > > > move from one a bit confusing state of the uapi to another one, without
> > > > real improvements.
> > > >
> > > > Ofc if all the compositor folks tell me that this doesn't matter anyway,
> > > > I'll shut up :-)
> > >
> > > Weston doesn't care - the effect is the same for us whether it's
> > > immutable or mutable-but-single-value.
> >
> > For KWin's current code it does matter that blob properties that are
> > only set from the kernel side and that the compositor should parse are
> > immutable; if EDID were to become mutable for example, that could
> > cause a regression for KWin.
> >
> > For properties like zpos, which the compositor is supposed to set on
> > some drivers, I'd prefer it if they were consistently never immutable.
>
> The zpos property is already sometimes immutable, e.g. for cursor planes.

I know, I'm arguing that should be changed. It's just a weird quirk
that doesn't change anything for compositors.

> --
> With best wishes
> Dmitry