<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Drew or Simon, does either of <a href="https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml" id="LPlnk">
https://github.com/swaywm/wlroots/blob/master/protocol/wlr-screencopy-unstable-v1.xml</a> or
<a href="https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml" id="LPlnk">
https://github.com/swaywm/wlroots/blob/master/protocol/wlr-export-dmabuf-unstable-v1.xml</a> 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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.<br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Frankly, weston_output_capture_v1's model that clients allocate the buffers would make it very difficult to support efficient screen capture for more than one simultaneous client. You can only target one writeback framebuffer per page flip. Having the compositor
manage the buffers' lifetimes and just publishing out handles (in the style of those two wlr extensions) to those probably fits better.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Matt</div>
<div id="appendonsend"></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<span style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><b>From:</b> Pekka Paalanen<br>
<b>Sent:</b> Friday, May 31, 2024 3:02 AM<br>
<b>To:</b> Hoosier, Matt<br>
<b>Cc:</b> Marius Vlad; wayland-devel@lists.freedesktop.org<br>
<b>Subject:</b> Re: Full-motion zero-copy screen capture in Weston </span>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-size: 11pt;">On Thu, 30 May 2024 13:40:15 +0000<br>
"Hoosier, Matt" <Matt.Hoosier@garmin.com> wrote:<br>
<br>
> Okay, interesting thoughts on all of that.<br>
><br>
> I'm not sure how far I'm going to get toward a complete overhaul of<br>
> the capture mechanism. Maybe it would be useful to know a couple<br>
> things about the current one (weston_output_capture_v1), so that I<br>
> don't commit mistakes that somebody already considered and guarded<br>
> against:<br>
><br>
> * Why was it explicitly picked only for still shots? I can image that<br>
> it wouldn't have been a whole lot more work to design this API with a<br>
> bounce-buffering scheme rather than a setup/do-it-once/destroy model.<br>
><br>
<br>
There was no need for streaming, as it was purely for the test suite.<br>
<br>
The test suite is very particular about when and how the shot is taken:<br>
it must be produced by the defined source, and it must be produced on<br>
the very next repaint of the output, exactly once.<br>
<br>
Did you mean a buffer pool (queueing/dequeueing) rather than<br>
bounce-buffering? Sure.<br>
<br>
> * Why was wl_shm explicitly picked for the buffer type? I was<br>
> thinking here that it would have worked equally well to specify that<br>
> the client must supply a linear-layout buffer manufactured through<br>
> zwp_linux_dmabuf. This would be eligible for direct targeting by the<br>
> GL renderer/KMS writeback, but also can be mapped with gbm_bo_map()<br>
> in the compositor's Pixman backend and/or a client who wants to map<br>
> it to the CPU upon delivery.<br>
<br>
Because the test suite specifically needs CPU access to the screenshot.<br>
There was no use yet for dmabuf, and GL-renderer was already doing<br>
glReadPixels() for screenshots.<br>
<br>
IOW, all the limitations are just "was not needed yet".<br>
<br>
Note, that re-using or extending the protocol extension<br>
weston_capture_v1 for streaming outputs for non-test-suite use cases<br>
may not be the best idea. If the interface needs to be a Wayland<br>
extension, then maybe something from the wlr extensions would suit<br>
better. OTOH, for e.g. Pipewire there would not be a Wayland extension<br>
used at all.<br>
<br>
The internal API (weston_output_capture) is very much geared for<br>
weston_capture_v1 only. The internal API might take improving rather<br>
than weston_capture_v1.<br>
<br>
<br>
Thanks,<br>
pq<br>
</div>
</body>
</html>