<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word"> <div class="WordSection1"> 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.<o:p></o:p> <o:p> </o:p> 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:<o:p></o:p> <o:p> </o:p> <ul style="margin-top:0in" type="disc"> <li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">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.<o:p></o:p></li></ul> <o:p> </o:p> -Matt<o:p></o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: Simon Ser <contact@emersion.fr> Date: Friday, May 31, 2024 at 10:16 AM To: Andri Yngvason <andri@yngvason.is> Cc: "Hoosier, Matt" <Matt.Hoosier@garmin.com>, Pekka Paalanen <pekka.paalanen@collabora.com>, "sir@cmpwn.com" <sir@cmpwn.com>, Marius Vlad <marius.vlad@collabora.com>, "wayland-devel@lists.freedesktop.org" <wayland-devel@lists.freedesktop.org> Subject: Re: Full-motion zero-copy screen capture in Weston<o:p></o:p> </div> <div> <o:p> </o:p> </div> <div> 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$ <o:p></o:p> </div> <div> <o:p></o:p> </div> <pre style="white-space:pre-wrap">On Friday, May 31st, 2024 at 16:45, Simon Ser <contact@emersion.fr> wrote:<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>> > See: <a href="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$</a><o:p></o:p></pre> <pre>> > <o:p></o:p></pre> <pre>> > > 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.<o:p></o:p></pre> <pre>> > <o:p></o:p></pre> <pre>> > Although the protocol is called "screencopy", it does not need to be<o:p></o:p></pre> <pre>> > implemented via copying. I don't think anything precludes drm<o:p></o:p></pre> <pre>> > write-back or rendering directly to the client-submitted buffers.<o:p></o:p></pre> <pre>> <o:p></o:p></pre> <pre>> Not sure that's true… With screencopy the client necessarily provides<o:p></o:p></pre> <pre>> buffers that the compositor copies into.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Correction: Andri said that it should be possible to pass client-allocated<o:p></o:p></pre> <pre>buffers to the writeback connector. There might be allocation considerations<o:p></o:p></pre> <pre>to take care of, but it might work fine indeed.<o:p></o:p></pre> </div> </body> </html>