-
Notifications
You must be signed in to change notification settings - Fork 341
Introduce wlr_output_layer #1985
base: master
Are you sure you want to change the base?
Conversation
ecf4d3f
to
133de32
Compare
It seems like this is designed so that |
I agree state duplication is not great, but there are several issues with this approach:
Let me know if any of the above is unclear or needs more explanation. |
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. |
I've investigated a little, and there are two things that could get in your way when testing this patch:
Does it help? |
133de32
to
7f74051
Compare
Rebased against master to fix the Alpine build failure. |
67c87c7
to
f4a9a8a
Compare
fe9e21e
to
fd003b7
Compare
See [1]. [1]: swaywm/wlroots#1985
See [1]. [1]: swaywm/wlroots#1985
See [1]. [1]: swaywm/wlroots#1985
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 |
d47fc8d
to
12a5457
Compare
Hmm, this is likely a bad idea in the end. We still want output layer changes to be applied on |
a1e50cf
to
c1c0dae
Compare
b411142
to
920dde0
Compare
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.
920dde0
to
e9295d6
Compare
wlroots has migrated to gitlab.freedesktop.org. This pull request has been moved to: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/1985 |
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:
Under the Wayland backend (where layers work as long as clients use
DMA-BUFs), thsi should display two surfaces.