<div dir="ltr"><div>I am trying to find a way through Weston which will allow setting specific encoding at display output. Could you please elaborate on why it is best to let DRM driver automatically configure which encoding to choose rather than making it selectable by DRM client ? I am not able to find reference to past discussion about this. I was only able to find a proposed change - <a href="https://lists.freedesktop.org/archives/intel-gfx/2017-April/125451.html">https://lists.freedesktop.org/archives/intel-gfx/2017-April/125451.html</a> but am not able to find why it got rejected.</div><div> </div><div>Alternatively, is there existing way through which DRM clients can specify preference for output encoding ? Or currently it's all up to the DRM driver to choose what output encoding to use. </div><div> </div><div>Thanks,</div><div>-Yogish </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 28, 2020 at 1:54 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 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 <<a href="mailto:daniel@ffwll.ch" target="_blank">daniel@ffwll.ch</a>> wrote: > > > 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> > > -- Daniel Vetter Software Engineer, Intel Corporation <a href="http://blog.ffwll.ch" rel="noreferrer" target="_blank">http://blog.ffwll.ch</a> </blockquote></div>