On Friday, May 31st, 2024 at 16:39, Andri Yngvason <an...@yngvason.is> wrote:
> Hi Matt, > > fös., 31. maí 2024 kl. 13:26 skrifaði Hoosier, Matt matt.hoos...@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.
