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 * 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. -Matt From: Simon Ser <cont...@emersion.fr> Date: Friday, May 31, 2024 at 10:16 AM To: Andri Yngvason <an...@yngvason.is> Cc: "Hoosier, Matt" <matt.hoos...@garmin.com>, Pekka Paalanen <pekka.paala...@collabora.com>, "s...@cmpwn.com" <s...@cmpwn.com>, Marius Vlad <marius.v...@collabora.com>, "wayland-devel@lists.freedesktop.org" <wayland-devel@lists.freedesktop.org> Subject: Re: Full-motion zero-copy screen capture in Weston On Friday, May 31st, 2024 at 16: 45, Simon Ser <contact@ emersion. fr> wrote: > > See: https: //urldefense. com/v3/__https: //gitlab. freedesktop. org/wayland/wayland-protocols/-/merge_requests/124__;!!EJc4YC3iFmQ!WaOP607PgstX4CpWrn4DV6X4TIDRrqQW5XEZfczyVDFZdkpmCfNDh0lUQetO5TuCK5ct4NVlCqcAz4-8ehlw$ On Friday, May 31st, 2024 at 16:45, Simon Ser <cont...@emersion.fr> wrote: > > See: > > https://urldefense.com/v3/__https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124__;!!EJc4YC3iFmQ!WaOP607PgstX4CpWrn4DV6X4TIDRrqQW5XEZfczyVDFZdkpmCfNDh0lUQetO5TuCK5ct4NVlCqcAz4-8ehlw$<https://urldefense.com/v3/__https:/gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124__;!!EJc4YC3iFmQ!WaOP607PgstX4CpWrn4DV6X4TIDRrqQW5XEZfczyVDFZdkpmCfNDh0lUQetO5TuCK5ct4NVlCqcAz4-8ehlw$> > > > > > My goal is to implement this screen capture with a guarantee that the > > > copy comes from a KMS writeback connector. I know this sounds like an odd > > > thing to insist on. Let's say that in my industry, the system is rarely > > > only running Linux directly on the bare metal. Using the writeback > > > hardware on the display controller allows to get a copy of content from > > > all the virtual machines in the system. > > > > Although the protocol is called "screencopy", it does not need to be > > implemented via copying. I don't think anything precludes drm > > write-back or rendering directly to the client-submitted buffers. > > Not sure that's true… With screencopy the client necessarily provides > buffers that the compositor copies into. Correction: Andri said that it should be possible to pass client-allocated buffers to the writeback connector. There might be allocation considerations to take care of, but it might work fine indeed.
