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@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 > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
