Full-motion zero-copy screen capture in Weston

[Simon Ser]

On Friday, May 31st, 2024 at 16:39, Andri Yngvason <andri at yngvason.is> wrote:

> Hi Matt,
> 
> fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt Matt.Hoosier at garmin.com:
> 
> > Hi,
> > 
> > Yeah. I agree that although I can prototype something quick and dirty here as a change to weston_output_capture_v1, it's probably not a good fit there.
> > 
> > Drew or Simon, does either of https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml or https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml strike you as a good fit for the use-case of getting a streamed copy of an output? They seem very similar – not sure what differentiates them from each other.
> 
> 
> I'd say ext-screencopy-v1 is pretty close to being complete. It is
> designed for both single shot capture and screen casting. It has 2
> acks and it has been implemented in wlroots, cosmic and wayvnc.
> 
> I would not recommend wlr-export-dmabuf for anything as it suffers
> from synchronisation issues. There are no guarantees for life-times of
> the dmabufs. wlr-screencopy works well enough, but ext-screencopy-v1
> is better.

For fixing the sync issue, there is:
https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/121

But not enough interest it seems.

> See: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124
> 
> > 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.