Full-motion zero-copy screen capture in Weston

[Hoosier, Matt]

> What do you mean you can capture all virtual machines with KMS
> writeback?
>
> What's the architecture there? How do virtual machines access KMS
> hardware? Why would Weston be able to capture their outputs at all?

I hope to have more to say about this shortly.

> The disadvantage is that buffer allocations are accounted to the
> compositor (which can manage its own memory consumption, sure), and
> either the compositor allocates a new buffer for every frame (possibly
> serious overhead) or it needs to wait for all consumers to tell that
> they are done with the buffer before it can be used again. Clients
> might hold on to the buffer indefinitely or just a little too long,
> which is the risk.

It seems to me this would be a risk of the existing Pipewire backend, no? At least, if I understood the buffering model of the dmabuf MR that Marius linked earlier.

On 6/3/24, 3:54 AM, "Pekka Paalanen" <pekka.paalanen at collabora.com <mailto:pekka.paalanen at collabora.com>> wrote:


On Fri, 31 May 2024 13:26:12 +0000
"Hoosier, Matt" <Matt.Hoosier at garmin.com <mailto:Matt.Hoosier at garmin.com>> wrote:


> 
> 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.
> 


What do you mean you can capture all virtual machines with KMS
writeback?


What's the architecture there? How do virtual machines access KMS
hardware? Why would Weston be able to capture their outputs at all?


> 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.


That's certainly true.


The disadvantage is that buffer allocations are accounted to the
compositor (which can manage its own memory consumption, sure), and
either the compositor allocates a new buffer for every frame (possibly
serious overhead) or it needs to wait for all consumers to tell that
they are done with the buffer before it can be used again. Clients
might hold on to the buffer indefinitely or just a little too long,
which is the risk.




Thanks,
pq