[PATCH i-g-t] tests/kms_properties: drop immutability checks
Xaver Hugl
xaver.hugl at kde.org
Fri Jul 19 11:55:22 UTC 2024
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.
> CCed some other compositor people too.
>
> Cheers,
> Daniel
More information about the igt-dev
mailing list