<div dir="ltr"><div>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 ? </div><div> </div><div>Thanks,</div><div>-Yogish </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 26, 2020 at 5:44 PM Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, May 26, 2020 at 9:39 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: > > On Tue, 26 May 2020 10:01:23 +0530 > Yogish Kulkarni <<a href="mailto:yogishkulkarni@gmail.com" target="_blank">yogishkulkarni@gmail.com</a>> 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 > <a href="mailto:dri-devel@lists.freedesktop.org" target="_blank">dri-devel@lists.freedesktop.org</a> > <a href="https://lists.freedesktop.org/mailman/listinfo/dri-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/dri-devel</a> -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - <a href="http://blog.ffwll.ch" rel="noreferrer" target="_blank">http://blog.ffwll.ch</a> </blockquote></div>