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

[Dmitry Baryshkov]

On Fri, 19 Jul 2024 at 15:48, Xaver Hugl <xaver.hugl at kde.org> wrote:
>
> 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.

Maybe I'm missing something. For some of the Qualcomm devices we have
generic planes which can have any zpos and in some cases a cursor
plane which must be the last one. Currently this can be represented by
using immutable zpos so we can make sure that the cursor plane is
always on the top. If the zpos is always mutable, we have no way to
tell userspace that this plane must be on top.


-- 
With best wishes
Dmitry