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. 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. Regards, Andri
