Full-motion zero-copy screen capture in Weston

[Marius Vlad]

Hi,

Note that systemd-udev will not work in a container. That usually
has the side effect of libinput not working either.

On Tue, Jun 04, 2024 at 08:33:48PM +0000, Hoosier, Matt wrote:
> 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?
With either seatd or logind. I suspect people use containers to build
but run it on the device.

> 
> [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20240605/7f7d316c/attachment.sig>