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

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry