Re: Dynamically change enumeration list of DRM enumeration property

[Yogish Kulkarni <yogishkulkarni@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3556 bytes --]

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 ?

Thanks,
-Yogish

On Tue, May 26, 2020 at 5:44 PM Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, May 26, 2020 at 9:39 AM Pekka Paalanen <ppaalanen@gmail.com>
> wrote:
> >
> > On Tue, 26 May 2020 10:01:23 +0530
> > Yogish Kulkarni <yogishkulkarni@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@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
>

[-- Attachment #1.2: Type: text/html, Size: 4690 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel