Full-motion zero-copy screen capture in Weston

[Hoosier, Matt]

Tactical question: I somehow missed until this point that the remote and pipewire plugins will only run if the DRM backend is being used.

But the DRM backend *really* doesn't want to start nowadays unless you're running on a system with seatd and/or logind available. Toolbox [1] is the de facto way to develop on bleeding edge copies of components these days. But it logind and seatd aren't exposed into it.

How do Weston people interactively develop on the Weston DRM backend nowadays?

[1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/

> -----Original Message-----
> From: Pekka Paalanen <pekka.paalanen at collabora.com>
> Sent: Tuesday, June 4, 2024 3:20 AM
> To: Hoosier, Matt <Matt.Hoosier at garmin.com>
> Cc: sir at cmpwn.com; contact at emersion.fr; Marius Vlad
> <marius.vlad at collabora.com>; wayland-devel at lists.freedesktop.org
> Subject: Re: Full-motion zero-copy screen capture in Weston
> 
> On Mon, 3 Jun 2024 17:57:18 +0000
> "Hoosier, Matt" <Matt.Hoosier at garmin.com> wrote:
> 
> > > 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.
> 
> I'm interested because I worry whether it will work. I don't see how it could
> work with the traditional display controllers and DRM drivers.
> 
> Maybe some kind of hardware assisted plane "leasing" that works around the
> DRM KMS software model limitations?
> 
> > > 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.
> >
> 
> I haven't looked at any of that, so I can't say. I don't know if pipewire is only
> allocate-send-forget, or does it include consumers signalling they are done to
> allow re-use as well. Or maybe the sources trust that rotating N buffers is
> always enough, and if a sink needs the data for longer, it will make a copy in
> time.
> 
> It's a trade-off. Sometimes the overhead of allocate-send-forget with the risk
> of OOM (KMS writeback might require a specific type of memory that could be
> scarce), maybe even with an added copy to avoid exhausting writeback-
> capable memory, may be justified.
> 
> 
> Thanks,
> pq