Full-motion zero-copy screen capture in Weston

[Hoosier, Matt]

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 <contact at emersion.fr>
Date: Friday, May 31, 2024 at 10:16 AM
To: Andri Yngvason <andri at yngvason.is>
Cc: "Hoosier, Matt" <Matt.Hoosier at garmin.com>, Pekka Paalanen <pekka.paalanen at collabora.com>, "sir at cmpwn.com" <sir at cmpwn.com>, Marius Vlad <marius.vlad at collabora.com>, "wayland-devel at lists.freedesktop.org" <wayland-devel at 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 <contact at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240531/9d617ebf/attachment-0001.htm>