Dynamically change enumeration list of DRM enumeration property

[Daniel Vetter]

On Tue, May 26, 2020 at 9:39 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Tue, 26 May 2020 10:01:23 +0530
> Yogish Kulkarni <yogishkulkarni at gmail.com> wrote:
>
> > Hi,
> >
> > Is it possible to dynamically change enumeration list of  DRM enumeration
> > property ? Motivation behind this question is to understand whether it is
> > possible to create connector enum property (e.g a property which will list
> > supported output encodings -  like yuv420, yuv422 etc) whose list of
> > supported enum values could be changed dynamically e.g. based on which sink
> > is connected.
> >
> > I think there is existing EDID connector property whose value changes based
> > on connected sink. EDID is a BLOB property, I am trying to understand if
> > this is also possible for ENUM type property. There is
> > "drm_property_replace_blob" to replace blob but I wasn't able to find any
> > API which could replace list of supported enums. Alternatively, would it be
> > good idea to destroy custom enum property created by a driver and create
> > new enum property with new list of supported enums e.g when there is a
> > HOTPLUG event.
>
> Hi,
>
> looking at Weston code, it *might* cope with it. A hotplug event does
> cause Weston to re-discover all properties of a connector. This is
> specific to connectors only.

Currently the kernel doesn't cope with that. Only objects which can be
added/removed are connectors, blobs and fbs (iow the refcounted ones).
Adding/removing properties isn't supported, nor is adding/removing
which properties are attached to which object while that object is
life.

Also I think the uapi risk for this is way too big, see my other reply
for what we've done in the past for stuff like this.
-Daniel

> The race exists though: userspace might be poking at KMS after you
> changed the property in the kernel but before userspace handles the
> hotplug event. You'd have to check that does not cause regressions. I
> guess for a completely new property, the risk seems low, as userspace
> does not know to poke at it (risk of using outdated property or value
> IDs causing unexpected atomic commit failure). Also I'm not aware of
> any KMS program that would yet attempt blind KMS state save & restore
> to sanitize the KMS state after dropping and re-gaining DRM master.
>
> You'd have to check all other KMS using programs too: every Wayland
> compositor, Xorg, DRM Vulkan WSI(?), ...
>
>
> Thanks,
> pq
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch