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
