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

[Xaver Hugl]

Am Fr., 19. Juli 2024 um 14:52 Uhr schrieb Dmitry Baryshkov
<dmitry.baryshkov at linaro.org>:
>
> 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.

zpos is a range property, you tell userspace the possible values with
a min and a max value. If they're the same, there's only one value for
userspace to use.

> --
> With best wishes
> Dmitry