On Fri, 31 May 2024 13:26:12 +0000 "Hoosier, Matt" <matt.hoos...@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
pgpKFYV6jmA3W.pgp
Description: OpenPGP digital signature
