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@xxxxxxxx> wrote:
On Tue, May 26, 2020 at 9:39 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote:
>
> On Tue, 26 May 2020 10:01:23 +0530
> Yogish Kulkarni <yogishkulkarni@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
