Skip to content

platforms/drm: rework output changes

Xaver Hugl requested to merge work/dynamic-crtcs into master

The number of available crtcs and which connector + crtc combinations can work together is constrained by hardware. Currently we're handling this for hotplugs but are ignoring it when KScreen requests changes and we're also ignoring outputs we can't drive completely. In practice this means that if you have a setup with such limitations some outputs may look like undetected in KScreen and changing settings can potentially fail. This will be especially important when we start using more bandwidth requiring color formats (-> deep color) and explicit modifiers and can already be an issue with the rgb range setting.

This MR does a few things to improve the situation:

  • Don't delete DrmPipelines when searching for a valid output configuration but instead have the pending crtc of a pipeline be dynamically adjustable
  • Every DrmConnector gets a DrmOutput created immediately; if we can't make the configuration work with it then it'll be disabled in KScreen instead of not there at all - and the user can disable a different output and enable the failed one. For DrmLeaseOutputs, always try to assign a crtc and if that's not possible then the lease requests simply fails
  • KScreen changes are applied atomically now. This means that all outputs on all GPUs are tested (with an atomic commit per GPU), and if anything would fail the changes get thrown out immediately
  • Wait for presentation if a modeset is pending, and commit all connected pipelines at once
  • When doing modesets, also include all resources we don't want to use. This is necessary to avoid for example having a crtc enabled without a connector, which could fail commits

What should maybe still be done is doing a modeset and enabling lease outputs before they're leased. I'd just wait and see for that; if necessary that shouldn't be a big problem

Edited by Xaver Hugl

Merge request reports