<div dir="ltr"><br><br>On Wed, Nov 20, 2024 at 4:22 AM Jani Nikula <<a href="mailto:jani.nikula@linux.intel.com">jani.nikula@linux.intel.com</a>> wrote:<br>><br>> Please avoid all struct edid based interfaces, in this case<br>> drm_connector_update_edid_property(). They will be removed in the<br>> future, and adding more is counter-productive. Everything should be<br>> struct drm_edid based going forward.<br>><br>> Of course, actually grafting the EDID needs struct edid. And that's kind<br>> of annoying too. Do we really want to spread the EDID details all over<br>> the place? This one combines drm_edid.h structs and magic numbers in a<br>> jumble. I'm kind of hoping we'd get rid of driver usage of struct edid,<br>> though that's a long road. But we've made a lot of progress towards it,<br>> there aren't that many places left that directly look at the guts of<br>> EDID, and most of it is centralized in drm_edid.c.<br>><br><br><div>drm_edid isn't exported so we can't use it. I know you've read the EDID spec so complaining about the magic numbers is silly.</div><div>I didn't choose to make the whole spec based on bizarrely packed 10 and 12 bit numbers, they are unavoidable.</div><br>><br>> > Maybe it resolves problems with<br>> > compositors, but it is a step backwards for the overall ecosystem. If<br>> > the connector changes, your driver should increment the epoch counter.<br>> > [1] That will send a hotplug event to userspace. The EDID alone does not<br>> > say anything about connector status.<br>><br>> Yeah, unplugging and replugging the same display with the same EDID<br>> isn't a problem for other drivers, and they don't have to do this kind<br>> of stuff to trick userspace. Maybe vmwgfx should handle (or simulate)<br>> hotplugs better?<br>><br>> And preferrably let the EDID functions handle epoch counter updates<br>> instead of doing it yourself, if at all possible.<br>><br>> BR,<br>> Jani.<br>><br><br>You're both missing the fact that virtual devices never disconnect active displays. We don't have to do a disconnect/connect cycle like a physical monitor and we wouldn't want to because it would be poor user experience. The issue is not sending the hotplug event, it's that userspace will ignore hotplug events on connectors that were previously connected because they assume a disconnect/connect cycle must occur for changes to occur. The whole point of hotplug_mode_update was as a hint to userspace that the display can be "re-plugged" without a disconnect first and to always rescan the connector for changes on hotplug.<br><br>Currently compositors are taking an arbitrary set of connector properties that they've organically collected over the years and doing a diff to trigger a refresh in the modes/display layout. EDID is the only property that they universally agree should trigger a display layout change. The fact that Autofit works on any compsitors using vmwgfx, qxl, or virtio is completely by accident.<br><br>EDID is also a standardized connector property so it's not really fair to say that all devices should export this property and then when we fix our deficiency to block it. Now that it's standardized it is part of the uapi and if userspace does weird things with it it's not really our concern. The fact that it's standardized is also likely the reason it is being used in such a fashion. <br><br>Ian,<br></div>