Skip to content

Libweston needs atomic output configuration API

The current output configuration API of libweston only allows reconfiguring disabled (inactive) outputs. This makes changing output configuration a very glitchy experience. An atomic output configuration API is needed, with the same spirit as the atomic KMS UAPI. #22 (closed) did not actually reach an atomic API.

A transaction based API is needed, because an output has many parameters. Changing each parameter one at a time would repeatedly apply intermediate configuration states for users and clients to see. Some of the consequences can be quite heavy, see #339 (comment 385588).

Second, since the hardware resources used by outputs are usually shared, the configuration of one output affects what is possible for another output. It would be good to be able to configure multiple outputs in one step to avoid intermediate configurations that might prevent the final configuration from being reached.

Third, with TEST_ONLY in the atomic KMS API, we would be able to test if a global output configuration will work. Using transactions for output configuration allows testing the complete configuration in one step to see if it is possible.

This issue partially closes #25 (closed) by recording the atomic API thoughts from the now inaccessible Phabricator document.

Atomic Libweston API

The libweston API needs to be atomic. It would probably be good to follow the DRM backend atomic state design somewhat. One needs to be able to construct a configuration covering all outputs, and test if it would work, then commit it as a whole to be taken into use on the next repaint cycle of each weston_canvas.

  1. Compositor constructs a tentative output configuration from canvases and heads.
  2. Compositor calls a test function with the tentative configuration.
  3. Test gets relayed to the DRM backend.
  4. DRM backend tries all the possible CRTC and connector combinations until it finds one that works, or returns test failed.
  5. Compositor:
  • If test failed: discards the tentative configuration.
  • If test succeeds: commits the tentative configuration, which schedules a repaint, which will then do the actual modesets.

Questions

  • What would the libweston API look like?
  • What parts of the API should be common and what parts should be backend-specific?
  • How to make the common API parts make sense to all the other backends?
  • How to stage a tentative configuration without modifying the current state in weston_canvas and weston_head?
  • How to re-use the atomic request helpers in the DRM backend with the tentative configuration?
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information