On Thu, Jul 16, 2026 at 10:37:24AM +0200, Luca Ceresoli wrote: > >> > Now if the bridges start doing it themselves we should go back to > >> > those encoder drivers and ditch all the drm_bridge_connector from > >> > there? > >> > > >> > I must be missing something. Can you elaborate on this? > >> > >> drm_bridge_connectors bring together a (complete) bridge chain and a > >> connector. If you don't have either anymore, then we shouldn't keep it > >> around. > >> > >> What I was suggesting before was only a suggestion. I guess we could > >> also make the encoder own the hotplug handling code and create the > >> drm_bridge_connector when the chain is complete, and remove it when it's > >> no longer the case. > > > > That's an interesting option. We don't have to keep drm_bridge_connector > > in its current form, but I don't think we should go back to individual > > bridge driver creating connectors, especially now that we have bridge > > chains where the connector ops are implemented collectively by multiple > > bridges. > > I definitely agree we don't want to add burden back on the encoder.
I don't think Laurent mentioned the encoder anywhere. > >> We can discuss alternatives too. But either way, we shouldn't have it > >> stick around. > > Bottom line, I roughly see three ideas mentioned: > > 1. (this series) extend the drm_bridge_connector to create the > drm_connector based on bridge hotplug events [+rename it] > 2. - keep the drm_bridge_connector (mostly) as is > - let each encoder driver add/remove it based on bridge hotplug events > => more burden on encoder drivers -> no Can you motivate that with *any* reason? Because I really feel like it's the best solution going forward. Maxime
signature.asc
Description: PGP signature
