Skip to content
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.

Introduce wlr_output_layer #1985

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

emersion
Copy link
Member

@emersion emersion commented Jan 9, 2020

This series add a new wlr_output_layer API, an implementation of this API in the Wayland backend and an example compositor.

My plan is to make glider switch to this API to demonstrate how it can be implemented under DRM.

Introduce wlr_output_layer

This new API allows compositors to display buffers without needing to
perform rendering operations. This API can be implemented on Wayland
using subsurfaces and on DRM using KMS planes.

The goal is to make use of this API in a future scene-graph API.

backend/wayland: implement the output layer API

The output layer API is implemented using subsurfaces. I chose to
implement this API in the Wayland backend before doing so in the DRM
backend, because it's way easier on Wayland. On DRM, one needs to figure
out how buffers can be mapped to KMS planes (libliftoff can help) and
perform atomic test-only commits (our current DRM backend isn't ready
for this).

examples: add output-layers example

This new example demonstrates how to use the wlr_output_layer API. It's
a compositor that displays all client surfaces using wlr_output_layer.
To test, one can for instance run:

build/examples/output-layers -s 'weston-simple-dmabuf-egl & weston-simple-egl'

Under the Wayland backend (where layers work as long as clients use
DMA-BUFs), thsi should display two surfaces.

@ddevault
Copy link
Contributor

It seems like this is designed so that wlr_output_layer is entirely siloed and responsible for its own state. This is going to lead to copying down the line. Why not make it an interface that each backend can implement? DRM with libliftoff, for example, which looks very similar. DRY up the sources of truth. Thoughts?

@emersion
Copy link
Member Author

It seems like this is designed so that wlr_output_layer is entirely siloed and responsible for its own state. This is going to lead to copying down the line. Why not make it an interface that each backend can implement? DRM with libliftoff, for example, which looks very similar. DRY up the sources of truth. Thoughts?

I agree state duplication is not great, but there are several issues with this approach:

  • A need a guarantee that nothing happens before wlr_output_commit. In particular, it should always be possible to cancel all pending changes with wlr_output_rollback (in case the commit fails, for instance). Rolling back is important because wlr_output_commit doesn't explain why a commit has failed, so the compositor wouldn't know what to do after a failed commit to perform a new non-failing commit. Neither Wayland nor libliftoff allow to rollback.
  • Ordering between layers needs to be tracked. On the DRM backend, the zpos property will be used. The backends code will be much simpler if the common code takes care of the wl_list stuff (backends can just iterate over the list of layers to update their state when the ordering changes). Once the ordering is tracked, it's very little work to keep track of other things like position or buffer.
  • The Wayland backend would need to track everything the common code currently tracks. One thing I think is important is making sure compositors can repeatedly change the pending state without any cost. It's pretty handy to be able to set the position of a layer at each frame, or to set the buffer to NULL then non-NULL in case importing it fails.

Let me know if any of the above is unclear or needs more explanation.

@ascent12
Copy link
Member

Hmm, the example doesn't seem to be showing anything for me other than the grey background. I can see the log messages from weston-simple-egl.

@emersion
Copy link
Member Author

emersion commented Jan 22, 2020

I've investigated a little, and there are two things that could get in your way when testing this patch:

Does it help?

@emersion
Copy link
Member Author

Rebased against master to fix the Alpine build failure.

@emersion emersion force-pushed the output-layers branch 2 times, most recently from 67c87c7 to f4a9a8a Compare March 9, 2020 11:39
@emersion emersion force-pushed the output-layers branch 3 times, most recently from fe9e21e to fd003b7 Compare April 9, 2020 15:45
emersion added a commit to emersion/glider that referenced this pull request Apr 9, 2020
emersion added a commit to emersion/glider that referenced this pull request Apr 9, 2020
emersion added a commit to emersion/glider that referenced this pull request Apr 10, 2020
@emersion
Copy link
Member Author

emersion commented Apr 30, 2020

Thinking about this again, this plan is probably not a good idea. Output layers are not like the rest of the output state. An output commit can succeed even if all layers are rejected by the backend, and this just means the compositor needs to draw these layers manually.

I think a better approach is not to make output layers part of the output state. This means wlr_output_rollback would not affect layers. So wlr_output_commit should probably not affect layers either.

@emersion emersion force-pushed the output-layers branch 3 times, most recently from d47fc8d to 12a5457 Compare May 6, 2020 12:50
@emersion
Copy link
Member Author

emersion commented May 6, 2020

I think a better approach is not to make output layers part of the output state.

Hmm, this is likely a bad idea in the end. We still want output layer changes to be applied on wlr_output_commit to ensure atomicity. If we start introducing some special cases ("a commit applies pending output state, plus output layers" and "a rollback reverts pending state, except output layers state"), then the API will become hairy pretty quickly.

@emersion emersion mentioned this pull request May 6, 2020
2 tasks
@emersion emersion mentioned this pull request Jun 8, 2020
6 tasks
@emersion emersion mentioned this pull request Nov 30, 2020
@emersion emersion force-pushed the output-layers branch 2 times, most recently from a1e50cf to c1c0dae Compare June 16, 2021 09:42
@emersion emersion force-pushed the output-layers branch 2 times, most recently from b411142 to 920dde0 Compare August 13, 2021 07:08
This new API allows compositors to display buffers without needing to
perform rendering operations. This API can be implemented on Wayland
using subsurfaces and on DRM using KMS planes.

The goal is to make use of this API in a future scene-graph API.

References: swaywm#1826
The output layer API is implemented using subsurfaces. I chose to
implement this API in the Wayland backend before doing so in the DRM
backend, because it's way easier on Wayland. On DRM, one needs to figure
out how buffers can be mapped to KMS planes (libliftoff can help) and
perform atomic test-only commits (our current DRM backend isn't ready
for this).
This new example demonstrates how to use the wlr_output_layer API. It's
a compositor that displays all client surfaces using wlr_output_layer.
To test, one can for instance run:

    build/examples/output-layers -s 'weston-simple-dmabuf-egl & weston-simple-egl'

Under the Wayland backend (where layers work as long as clients use
DMA-BUFs), this should display two surfaces with remote wl_subsurfaces.
@emersion
Copy link
Member Author

emersion commented Nov 1, 2021

wlroots has migrated to gitlab.freedesktop.org. This pull request has been moved to:

https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/1985

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants