Dynamically change enumeration list of DRM enumeration property

[Daniel Vetter]

On Thu, May 28, 2020 at 12:29:43PM +0530, Yogish Kulkarni wrote:
> For creating new source property, is it good to follow
> "drm_mode_create_hdmi_colorspace_property()"  as an example ? It seems that
> currently there is no standard DRM property which allows DRM client to set
> a specific output encoding (like YUV420, YUV422 etc). Also, there is no
> standard property for letting client select YUV/RGB color range. I see
> there are two ways to introduce new properties, 1. do something like
> drm_mode_create_hdmi_colorspace_property 2. create custom property similar
> to "Broadcast RGB". Is there opinion on which is a preferable way to expose
> encoding and color rage selection property ?

I guess first question is "why?" Thus far we've gone with the opinion that
automatically configuring output stuff as much as possible is best. What's
the use-case where the driver can't select this?
-Daniel

> 
> Thanks,
> -Yogish
> 
> On Tue, May 26, 2020 at 5:44 PM Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> > 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
> >

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch