This MR contains a completely new Weston-specific screenshooting protocol designed to support:
- color management testing by adding the "blending" source
- KMS testing by adding the "writeback" source
- output decorations testing by adding the "full_framebuffer" source
- proper buffer size negotiation instead of guessing from wl_output
- compositor chosen pixel format, primarily for "blending" source
- proper indication of screenshot failure
- dmabuf target buffers, linear only
The new protocol extension should be good enough to make a public Weston extension with stability guarantees, and install the XML file.
This is not a 100% implementation of the protocol. The notable omissions are:
- support for dmabuf, even though the protocol would allow using them
- "writeback" source support in DRM-backend (see !458 (merged))
- "blending" source support in GL-renderer (I don't expect that to be a problem, but not needed yet)
I do implement:
- The full logic for the new output capture (screenshooting) protocol.
- Pixman-renderer supports both "framebuffer" and "blending" sources.
- GL-renderer supports "framebuffer" and "full-framebuffer" blending sources.
- The test suite client helpers are converted to the new protocol.
- The manual screenshooting helper client is converted to the new protocol.
The new compositor side logic is very different from the old one. With the old approach you registered a
frame_signal listener on an output, and when you get called, you are allowed to call
weston_renderer::read_pixels to get something in some orientation and layout.
In the new approach, we keep a list of pending capture tasks with each output. When a renderer (or backend) processes an output repaint, it checks for capture tasks of the appropriate pixel source, and performs those capture tasks on its own, writing into the referenced
weston_buffer. The capture source providers (renderers and backends) decide in advance what size and pixel format the destination buffers must have. This might save the provider from format conversion, pushing that out of the compositor. It also allows using higher precision pixel formats.
The old screenshooting protocol and its implementation are removed. However,
weston_screenshooter_shoot() API is still retained as deprecated because it has external users. I expect to remove it in a Weston release after the next one.
Unfortunately, this work does not completely replace the output frame signal and
weston_renderer::read_pixels API. Screen-share plugin and the wcap recorder still need
read_pixels. I would guess that screen-share would be far better off if it could use dmabuf and/or pipewire in the future. The current
read_pixels path looks quite inefficient. It is also a good question if anyone would miss the wcap recorder (ad hoc run-length encoded software compression). Therefore it might be possible to remove the
read_pixels API in the far future.
The real reason why I embarked on this task right now is that in the CM&HDR work I want to test the input-to-output category of color transformations. The only place where that category is used is output decorations in the Weston wayland-backend. I need a way to take screenshots of those decorations to check their colors. Quickly hacking something up in the old screenshooting protocol did not seem like a good idea.
Closes: #449 (closed)