<div dir="ltr"><div>Thanks, Daniel & Pekka.</div><div><br></div><div>It might be bad idea to destroy and re-create the connector enum property from HOTPLUG handler in DRM. But if this is done through DRM_IOCTL_MODE_GETCONNECTOR, there won't be race, right ? From code walk through it seems that Weston will call this IOCTL for newly connected display found through HOTPLUG event and DRM driver will update the EDID through the call sequence triggered by this IOCTL. On the similar line if existing connector property is destroyed and re-created with new enmu list through this IOCTL call chain, then there won't be race ?</div><div><br></div><div>Thanks,</div><div>-Yogish<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 26, 2020 at 1:09 PM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br></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, 26 May 2020 10:01:23 +0530<br>
Yogish Kulkarni <<a href="mailto:yogishkulkarni@gmail.com" target="_blank">yogishkulkarni@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
> <br>
> Is it possible to dynamically change enumeration list of  DRM enumeration<br>
> property ? Motivation behind this question is to understand whether it is<br>
> possible to create connector enum property (e.g a property which will list<br>
> supported output encodings -  like yuv420, yuv422 etc) whose list of<br>
> supported enum values could be changed dynamically e.g. based on which sink<br>
> is connected.<br>
> <br>
> I think there is existing EDID connector property whose value changes based<br>
> on connected sink. EDID is a BLOB property, I am trying to understand if<br>
> this is also possible for ENUM type property. There is<br>
> "drm_property_replace_blob" to replace blob but I wasn't able to find any<br>
> API which could replace list of supported enums. Alternatively, would it be<br>
> good idea to destroy custom enum property created by a driver and create<br>
> new enum property with new list of supported enums e.g when there is a<br>
> HOTPLUG event.<br>
<br>
Hi,<br>
<br>
looking at Weston code, it *might* cope with it. A hotplug event does<br>
cause Weston to re-discover all properties of a connector. This is<br>
specific to connectors only.<br>
<br>
The race exists though: userspace might be poking at KMS after you<br>
changed the property in the kernel but before userspace handles the<br>
hotplug event. You'd have to check that does not cause regressions. I<br>
guess for a completely new property, the risk seems low, as userspace<br>
does not know to poke at it (risk of using outdated property or value<br>
IDs causing unexpected atomic commit failure). Also I'm not aware of<br>
any KMS program that would yet attempt blind KMS state save & restore<br>
to sanitize the KMS state after dropping and re-gaining DRM master.<br>
<br>
You'd have to check all other KMS using programs too: every Wayland<br>
compositor, Xorg, DRM Vulkan WSI(?), ...<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div>