Hi Matt, fös., 31. maí 2024 kl. 15:34 skrifaði Hoosier, Matt <matt.hoos...@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
