Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce wlr_output_layer #1985
This series add a new
My plan is to make glider switch to this API to demonstrate how it can be implemented under DRM.
This new API allows compositors to display buffers without needing to
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
examples: add output-layers example
This new example demonstrates how to use the wlr_output_layer API. It's
Under the Wayland backend (where layers work as long as clients use
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.
I've investigated a little, and there are two things that could get in your way when testing this patch:
Does it help?
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), thsi should display two surfaces.