Prune DRM modifier list when enabling a new output
Enabling a new output with other outputs already existing can fail for the first modifier that GBM picks. An example of this is running out of available bandwidth on Intel when using a specific modifier for one output, leaving very little room to enable any other output.
Therefore, Weston should do something like this when enabling a new output:
- Get the primary plane
IN_FORMATSas the modifier list.
- Create a GBM surface with the modifier list.
gbm_surface_lock_front_buffer()to get a buffer.
- Do a
TEST_ONLYatomic commit with the buffer on the primary plane.
- If the test commit fails, remove the modifier used by the buffer from the modifier list, destroy the GBM surface, and go to 2.
But this is not enough, if an existing output is using a modifier that consumes all available resources. Therefore if the modifier list becomes empty, we have to start pruning the modifier lists of other outputs and then repeat the above at each step.
But this leads to combinatorial explosion to test: on which existing output do you drop the current modifier first? Second? Then?