Fix how we map DRMConnectors to DRMCRTCs

Our current method for attaching DRMConnectors to DRMCRTCs is naive and probably won't work well for multiple monitors. Additionally, it doesn't allow for customisation.

We want to be able to specify groups of DRMConnectors which should have the same output on them, and then select the most suitable DRMCRTC for each group. The most suitable DRMCRTC will be the one which supports the best mode for each DRMConnector: that is, the one with the closest aspect ratio, resolution and refresh rate. We could determine the best DRMCRTC for each DRMConnector group by iterating over each possible configuration and computing some score which encapsulates how good a fit that DRMCRTC is for the DRMConnector group, then once we have the best DRMCRTC for each group, we can do modesetting for each DRMCRTC. To prevent this taking too long, we can try a limited number of configurations, ordered heuristically (e.g. try to find the best DRMCRTC for the biggest DRMConnector group first).

We should also take into account the power status of each DRMConnector (possibly using the DPMS property, or an non-legacy source of the same information).

We need some way to describe the groups. Ideally, we would be able to use some identifier for each DRMConnector, such as the EDID property, or something similar. We could use the connector type too. We would put the identifiers into a vector of vectors (or similar), then pass that to the optimiser, which would determine the best configuration, before performing the actual modesetting.

How do encoders play into this? What about daisy-chaining?

donotturnoff / display

Fix how we map DRMConnectors to DRMCRTCs #14