Full-motion zero-copy screen capture in Weston

[Andri Yngvason]

Hi Matt,

fös., 31. maí 2024 kl. 15:34 skrifaði Hoosier, Matt <Matt.Hoosier at garmin.com>:
>
> Thanks, understood. I would expect that I need to take some care in allocating a buffer that my DRM driver accepts for writeback, in this usage.
>
>
>
> Do I interpret right that the wlroots screencopy extension wants the client to create a fresh zwlr_screencopy_frame_v1 for each successive frame? I wonder then:
>
>
>
> * Whether this might lead to the possibility of dropped frames, if the client doesn’t manage to send back the requests to start capture for frame N+1 soon enough after the delivery of the copied buffer for frame N; and

If you send a frame request as soon as you receive an update, frames
will not be dropped.

> * Will the explicit request for each frame via zwlr_screencopy_frame_v1:: copy(), result in artificial redraws to satisfy the request? Ideally I would just like to receive a passive copy of each frame that naturally got drawn by the compositor. Perhaps with one artificial redraw at the very beginning of the screencopy stream just to have a defined starting point.

For wlr-screencopy-v1, you can use the the "copy_with_damage" request
to avoid "artificial redraws". See:
https://wayland.app/protocols/wlr-screencopy-unstable-v1#zwlr_screencopy_frame_v1:request:copy_with_damage

For ext-screencopy-v1, when you create a session, a redraw may be
required for the first frame. After that, only damaged frames are
copied for that session. See:
https://wayland.app/protocols/wayland-protocols/124

Regards,
Andri