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.paala...@collabora.com> > > Sent: Tuesday, June 4, 2024 3:20 AM > > To: Hoosier, Matt <matt.hoos...@garmin.com> > > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad > > <marius.v...@collabora.com>; wayland-devel@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.hoos...@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
signature.asc
Description: PGP signature
