Hi, On Mon, Jul 15, 2024 at 11:38:58AM GMT, Thomas Zimmermann wrote: > For CRTCs with multiple outputs (i.e., encoders plus connectors), > only report at most a single connected output to userspace. Make > this configurable via CONFIG_DRM_REPORT_SINGLE_CONNECTED_CRTC_OUTPUT. > > Having multiple connected outputs on the same CRTC complicates > display-mode and format selection, so most userspace does not > support this. This is mostly not a problem in practice, as modern > display hardware provides a separate CRTC for each output. Do they? At least the RaspberryPi has multiple connectors on a single CRTC, and for multiple CRTCs. My understanding is that it's definitely expected, and any decent user-space should expect it. Did you have any bug with this? And if it was the case, we wouldn't support cloning at all. I couldn't really find how cloning works exactly, but my understanding was that it's the difference between drm_encoder.possible_crtcs and possible_clones: possible_crtcs lists the CRTCs it can be connected to, and possible_clones the other encoders that can run with in parallel. > On old hardware or hardware with BMCs, a single CRTC often drives > multiple displays. Only reporting one of them as connected makes > the hardware compatible with common userspace. > > Add the field prioritized_connectors to struct drm_connector. The > bitmask signals which other connectors have priority. Also provide > the helper drm_probe_helper_prioritize_connectors() that sets > default priorities for a given set of connectors. Calling the > helper should be enough to set up the functionality for most drivers. > > With the prioritization bits in place, update connector-status > detection to test against prioritized conenctors. So when the probe > helpers detect a connector as connected, test against the prioritized > connectors. If any is also connected, set the connector status to > disconnected. > > Please note that this functionality is a workaround for limitations > in userspace. If your compositor supports multiple outputs per CRTC, > CONFIG_DRM_REPORT_SINGLE_CONNECTED_CRTC_OUTPUT should be disabled. > > Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx> The whole "is it actually needed" discussion aside, I'm not sure it's a good idea to use a config option for that. Chances are distros will either enable it or disable it depending on what they/their customers workload will typically look like, and it won't make the kernel or compositor's job any easier. Could we use a client capability for that maybe? Maxime
Attachment:
signature.asc
Description: PGP signature
