Clone mode / atomic output configuration in libweston
Submitted by Pekka Paalanen @pq
Assigned to Pekka Paalanen @pq
Description
There are demands for implementing clone mode. Below is a quote from [[ https://lists.freedesktop.org/archives/wayland-devel/2017-March/033422.html | an email I wrote ]]:
There are at least three different ways of doing clone mode:
- A single CRTC driving several encoders/connectors
This is the most power-efficient.
Not always possible due to hardware limitations.
The monitors must have the same video timings and resolution.
The monitors are guaranteed to be frame-locked to always show the
same image (unless the monitors themselves have different latencies
etc.)
- Creating framebuffers individually for each CRTC/connector
The most flexible approach: monitors can have different timings,
different resolutions, highly different pixel densities, different
areas of the desktop to show, etc.The most power-hungry approach: a compositing pass is needed per
monitor per frame.The monitors run asynchronously to each other (good or bad, depending
on what you need).Requires re-designing Weston's internal damage tracking.
- Sharing framebuffers between CRTCs
The most complicated approach to implement, because you have several
CRTCs running asynchronously, but you still have just one buffer flip
queue.Prone to reduced framerates and framerate jitter.
Might be as power-efficient as option 1, or as wasteful as option 2.
Unclear what the buffer flip queue management algorithm should look
like, would probably need a pool of framebuffers rather than just the
usual double-buffering to allow updating monitors somewhat
independently.Unclear whether this mode actually has real benefits over the other
two.A big portion of the needed effort is designing how the libweston API to configure outputs should look like so that it can support all kinds of clone modes and give the user (the compositor) a full freedom in configuring it while preferably not exposing the full nightmare of CRTCs and connectors. I suspect the output configuration API also needs to change to become atomic so that the user can configure everything and push it in in one go, with a test before final commit to check it actually can work. This will relate to and likely depend on the atomic modesetting patch series.
Internally, it involves re-designing what a struct weston_output is, splitting some new objects out of it, and defining their roles and relationships. Some will be exposed in the libweston API, some will be internal.
Design libweston API for atomic output configuration in a way that it supports also setting up clone mode in various ways, and implement it.
Prerequisites:
- atomic modesetting
Possibly nice to merge first:
Cooperate with Armin to avoid clashes with his output work.
Draft: [[wayland/weston/atomic-output-config]]
Implementation progress:
[x] Design a libweston API that will allow configuring clone mode.
[x] Implement the API in libweston core in a way to allow gradual migration of Weston frontends and backends to the new API with full bisectability.
[x] Convert Weston frontends (main.c) to the new API.
[x] Convert headless-backend to the new API.
[x] Convert DRM-backend to the new API.
[x] Convert fbdev-backend to the new API.
[x] Convert wayland-backend to the new API.
[x] Convert x11-backend to the new API.
[x] Convert RDP-backend to the new API.
[x] Clean up libweston core from compatibility code that allowed the gradual migration.
[x] Implement shared CRTC clone mode support in Weston frontend, make it configurable in weston.ini.
[x] Implement shared CRTC clone mode in DRM-backend.
[x] Rebase everything on top the atomic modesetting series once it has been merged upstream.
I should probably have a follow-up task for the independent CRTCs clone mode as it involves fixing the damage tracking.