Bug#1031284: RFS: wl-mirror/0.12.2-1 [ITP] -- output-mirroring tool for wlroots-based Wayland desktops
Hi Josch,
On 20 February 2023 07:48:32 CET, Johannes Schauer Marin Rodrigues <josch@debian.org> wrote:
>Hi Ferdinand,
>
>in #1012684 Antoine Beaupré said they'd be happy to sponsor you. Did They
>already contact you about that?
Yes, Antoine contacted me and gave me some very useful guidance on how to get the package closer to completion. He also told me about the RFS process and that he would be happy to sponsor it :)
I made this RFS mostly because I thought it is a necessary part of the process of submitting a package as an external to the project.
>Quoting Ferdinand Bachmann (2023-02-14 16:41:49)
>> Alternatively, you can download the package with 'dget' using this command:
>>
>> dget -x
>> https://mentors.debian.net/debian/pool/main/w/wl-mirror/wl-mirror_0.12.2-1.dsc
>>
>> Additionally, my current development tree for the Debian source package,
>> including scripts/Dockerfiles (since I am developing this on a
>> non-Debian system) is the following URL:
>>
>> https://github.com/Ferdi265/wl-mirror-debian
>
>I tried out your package and it works great on my ARM Cortex A57 platform. How
>does it manage to not consume any CPU even when recursively mirroring itself?
wl-mirror by default uses the wlr-export-dmabuf protocol extension to receive frames from the compositor. The compositor hands wl-mirror a dmabuf handle, which is a handle to frame data already in VRAM on the GPU. Importing it into EGL and rendering to the screen therefore does not include copying it to the CPU and back, which is why the CPU overhead does not depend that much on screen resolution and activity in the image.
On some devices, that doesn't work though, and wl-mirror does have a fallback mode using the wlr-screencopy protocol extension where it receives the frame data on the CPU via shared memory (--backend screencopy), which is heavier on the CPU than just transmitting a handle.
Both of these only work on wlroots-based compositors like sway, though. Support for other compositors like KWin and Gnome is something I have planned, but will still need a lot more work, since I have to use XDG Portals and Pipewire to receive the screen data, and I also need to add window decorations to make it usable on those compositors.
>Thanks!
>
>cheers, josch
Thank _you_ :)
Cheers, Ferdinand
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: