Hi Dmitry, Thanks for your comments > Could you please clarify, why do you want to use intel_connector for the > writeback connector? > I can see a usecase for sharing an encoder between the display and writback > pipelines (and if I'm not mistaken, this is the case for Abhinav's case). > However, sharing the hardware-backed connector and writeback connector > sounds like a sign of a loose abstraction for me. > > Please correct me if I'm wrong and Intel driver would really benefit from > reusing intel_connector as a base for drm_writeback_connector. > The thing is drm_writeback_connector contains drm_connector and drm_encoder fields which get initialized when we call drm_writeback_connector_init adding the connector to the list of connectors for the drm_device. Now if I decide not to wrap drm_writeback_connector with intel_connector the issue is I'll have to add a lot of checks all over the driver to see if the drm_connector is actually present inside intel_connector or not. I don’t see the point of not having drm_writeback_ connector as even though it’s a faux connector we still treat is as a connector and it would be better for us to use intel_connector for writeback_connector. Also the current drm_writeback_connector structure kind of restricts drivers consequently dictating how they implement their writeback functionality, as a midlayer I don't feel that would be the right approach as drivers should have the freedom to develop their own flow to implement the functionality and use the midlayer as a helper to get that done. Best Regards, Suraj Kandpal
