The previous implemented way to use wlr_screencopy events to cicle the
screencast had issues, like halting the stream if it was paused and
resumed before PipeWire triggered a recreation of buffers. This came
from not returning a dequeued buffer. This is now mititgated by
enqueuing the current pw_buffer imidiately on a paused event and trying
to dequeue a buffer just before requesting a screencopy if none is
present.
It showed that handling self contained buffers is much easier then have
the metadata of the buffer seperated from the actual buffer attached to
the screencast instance.
The goal of the following changes is to separate the meta informations
like requested buffer attributes and wlr_screencast data from the actual
buffers.
This enables us to:
* Simplify the flow between the PipeWire loop and the wlroots one
* Track and apply damage to each used buffer (ext_screencopy)
A PipeWire client might pause the stream which enables us to stop
requesting buffers from the compositor. In this case the the quit bool
won't be enacted on and thus we should destroy it directly from here.
We can trigger that with pw_stream_trigger_process when we are the
driver of the stream. Additionally this let's us run passivly with the
consumer driving the stream.
When a buffer is destroyed while used in the copy_buffer request the
screencopy protocoll will answer with the failed event. This can happen
anytime when PipeWire calls the remove_buffer callback, eg. on
renegotiation. This is not fatal, so we don't need to close the
screencast.
cast->err should only be used for fatal errors.
PipeWire can request to destroy the allocated buffers anytime. This
isn't a problem for us, since the screencopy protocol can handle
disappearing buffers. The only thing we have to do is not to use a
destroyed buffer.
The enum xdpw_frame_state is used to track the state of the xdpw_frame through
the screencopy callbacks. xdpw_wlr_stream_finish is used as the new
endpoint of the screencopy callbacks. Here we clean up the
screencopy_frame, enqueue the pipewire buffer and restart the screencopy
loop if needed.
Sometimes it can happen that the first frame of the active stream
triggers the renegotiation and destroy the frame without copy and with
that starting the fps_limit counter. This triggers an assert in
fps_limit_measure_end. To avoid it, we only engage the fps_limiter after
a frame was copied successfully.
Instead of using one wl_buffer to export buffers from wlroots and then
copy the content into the buffer dequed from pipewire, we can create a
wl_buffer for each pipewire buffer directly at allocation time and
attach it to the data attribute. Those wl_buffers can be directly handed
over to the wlroots screencopy protocol and so removing one copy.
Since we gather the information of the currently used buffer on
importing it, we can check if the imported and the announce buffer by
wlroots are compatible.
Also the comparison between the announced buffer properties and the
format used by the pipewire stream was moved to wlr_frame_buffer_done.
This lets us implement all checks in the same callback and makes it
easier to extend those checks for future dmabuf sharing.
Since we are driving the screencast there are no events on the pipewire loop
calling the on_event callback. We want to import and export (if possible) on
every frame of the wlroots loop, so this event is no longer needed.
The default node_id is SPA_ID_INVALID.
We are casting pipewire uint32_t node_id to int for printing since they are
currently staying in the range of low integer numbers. This makes
spotting an uninitialized node_id (casted to -1) much easier. Should be
corrected if that becomes an issue in the future.
This makes xdpw exit when either the D-Bus daemon, the Wayland
compositor or Pipewire is shut down. This avoids having dangling
non-functional xdpw instances, e.g. when restarting the compositor.
To test, start Sway nested in Sway, run xdpw with
WAYLAND_DISPLAY=wayland-2, and exit the nested Sway.
