Created attachment 239219 [details] unconditional (rtc_link_pipewire=false) PipeWire-based screen capture is complex replacement[1] for wlr-screencopy-unstable-v1 (wlroots, MirServer >= 2.8, to be standardized[2]), primarily designed for sandboxing apps via Flatpak or similar. It can work under both X11 and Wayland but most consumers limit it to Wayland. See also other xdg-desktop-portal examples: - org.freedesktop.portal.ScreenCast: firefox-esr, obs-studio, kooha - org.freedesktop.portal.Screenshot: flameshot, ksnip, gimp-app This expands ports 8fc70d7e9054 to include Screen Capture in WebRTC. With rtc_link_pipewire=false (upstream default) libpipewire is used via dlopen(3), so it can always be enabled like Wayland support. "poudriere bulk -t" passed on 13.1 amd64. Runtime tested inside 13.1 jail on 14.0 host under Sway with X11/Wayland/DBus sockets passed through. Works fine both under native Wayland and Xwayland. Runtime testing recipe: # pkg install chromium sway pam_xdg xdg-desktop-portal-wlr xdg-desktop-portal # echo 'session optional pam_xdg.so notroot runtime' >>/etc/pam.d/system # sysrc seatd_enable=YES # service seatd start $ exit # log out to pick up XDG_RUNTIME_DIR <new login> $ dbus-daemon --session --fork --address=unix:runtime=yes $ export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus # workaround $ sway <GUI session> $ export XDG_CURRENT_DESKTOP=sway $ dbus-update-activation-environment --all $ daemon -f pipewire $ daemon -f /usr/local/libexec/xdg-desktop-portal # workaround $ daemon -f /usr/local/libexec/xdg-desktop-portal-wlr # workaround $ chrome - open chrome://flags - enter "wayland" in Search field - set "WebRTC PipeWire support" to "Enabled" - set "Preferred Ozone platform" to "Auto" - click Relaunch - open https://mozilla.github.io/webrtc-landing/gum_test.html - click on "Screen Capture" - click on "Entire Screen" tab in "Choose what to share" prompt - click anywhere to select the desired output/monitor - notice preview is filled with screen content - click "Share" to confirm - click anywhere to select the desired output/monitor - watch screen content mirrored on the web page - click on "Stop Sharing" to end the capture or just close the browser References: [1] https://blogs.kde.org/2020/10/11/linux-desktop-shell-ipc-wayland-vs-d-bus-and-lack-agreement-when-use-them [2] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124
Created attachment 239220 [details] port option (rtc_link_pipewire=true) Untested alternative maybe easier to debug on pipewire updates i.e., sync files/patch-pipewire_init
Created attachment 239341 [details] port option (rtc_link_pipewire=true) files/patch-pipewire_init shouldn't be necessary when linking directly as <pipewire/pipewire.h> already has: /* BSD has pw_init already */ #define pw_init pipewire_init #define pw_deinit pipewire_deinit Like before, this version hasn't been build/runtime tested.
Comment on attachment 239341 [details] port option (rtc_link_pipewire=true) (In reply to Jan Beich from comment #2) > Like before, this version hasn't been build/runtime tested. Finally tested: builds and works fine on 13.1 amd64.
Comment on attachment 239219 [details] unconditional (rtc_link_pipewire=false) files/patch-pipewire_init can be dropped here as well. www/chromium builds against system pipewire headers unlike www/firefox-esr which bundles those, so pw_init -> pipewire_init should work for *.c and *.cc files, not sure about *.sigs. Either this needs runtime testing and confirming "chrome" doesn't reference pw_init symbol.
(In reply to Jan Beich from comment #0) Oops, "Runtime testing recipe" forgot to mention the user has to be in "video" group to be able to use seatd or /dev/dri/* (Xorg gets by via setuid bit) i.e., "pw groupmod video -m <user>" as described in "pkg info -D seatd". Due to bug 191677 it's not possible to avoid confusion via amedments scattered within a bug.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ca9744daf3266b182a330b3fcbd4d6d5f85a6e22 commit ca9744daf3266b182a330b3fcbd4d6d5f85a6e22 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2023-01-02 07:06:47 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2023-08-18 21:00:52 +0000 www/*chromium: enable PipeWire for screen sharing on Wayland PR: 268726 Approved by: maintainer timeout (7 months) www/chromium/Makefile | 13 +++++++++++-- ...les_desktop__capture_linux_wayland_egl__dmabuf.cc (new) | 14 ++++++++++++++ www/iridium/Makefile | 14 +++++++++++--- ...les_desktop__capture_linux_wayland_egl__dmabuf.cc (new) | 14 ++++++++++++++ www/ungoogled-chromium/Makefile | 13 +++++++++++-- ...les_desktop__capture_linux_wayland_egl__dmabuf.cc (new) | 14 ++++++++++++++ 6 files changed, 75 insertions(+), 7 deletions(-)
Landed what is easier to maintain. chromium is already bloated, so pipewire doesn't add much[1]. OTOH, pulsaudio via alsa-plugins bloat is attributed to lack of subpackaging (review D40549). [1] For example, $ pkg install -qy chromium $ pkg install -n pipewire Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 15 package(s) will be affected (of 0 checked): New packages to be INSTALLED: alsa-lib: 1.2.2_1 alsa-plugins: 1.2.2_12 consolekit2: 1.2.6_1 fftw3: 3.3.10_3 fftw3-float: 3.3.10_3 gstreamer1: 1.22.5 gstreamer1-plugins: 1.22.5 iso-codes: 4.7 libevdev: 1.9.1.20200928 libinotify: 20211018 libsoxr: 0.1.3_3 orc: 0.4.34_1 pipewire: 0.3.62_3 pulseaudio: 16.1_1 webrtc-audio-processing0: 0.3.1_3 Number of packages to be installed: 15 The process will require 71 MiB more space.
(In reply to Jan Beich from comment #0) > $ dbus-daemon --session --fork --address=unix:runtime=yes > $ export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus # workaround > $ sway > <GUI session> > $ export XDG_CURRENT_DESKTOP=sway > $ dbus-update-activation-environment --all > $ daemon -f pipewire > $ daemon -f /usr/local/libexec/xdg-desktop-portal # workaround > $ daemon -f /usr/local/libexec/xdg-desktop-portal-wlr # workaround To fix DBus activation (avoid manually starting services) run like this: $ dbus-run-session sway <GUI session> $ export XDG_CURRENT_DESKTOP=sway $ dbus-update-activation-environment --all $ daemon -f pipewire Note, x11/mako works fine *without* dbus-run-session or even $DBUS_SESSION_BUS_ADDRESS (as long as $XDG_RUNTIME_DIR/bus exist). No need for dbus_enable=YES in rc.conf(5) to use DBus services run as regular user. For example, Chromium only needs dbus_enable=YES for battery status (via sysutils/upower) per https://source.chromium.org/search?q=dbus::Bus::SYSTEM&sq=&ss=chromium
(In reply to Jan Beich from comment #8) Nevermind, after inspecting DBus activation[1] it appears DBus was confused between services available in and outside of jail. It was specific to my testing setup "with X11/Wayland/DBus sockets passed through". Host session bus didn't see the new files under /usr/local/share/dbus-1/services. Merging filesystems is tricky (if not dangerous) but so is filtering via xdg-dbus-proxy, so it's easier to just prepend dbus-run-session to cut off from the host. [1] $ dbus-send --print-reply --session --type=method_call \ --dest=org.freedesktop.DBus / org.freedesktop.DBus.ListActivatableNames method return time=12345.67890 sender=org.freedesktop.DBus -> destination=:1.1 serial=3 reply_serial=2 array [ string "org.freedesktop.DBus" string "org.freedesktop.Notifications" string "org.a11y.Bus" string "ca.desrt.dconf" ] $ dbus-run-session dbus-send --print-reply --session --type=method_call \ --dest=org.freedesktop.DBus / org.freedesktop.DBus.ListActivatableNames method return time=12345.67890 sender=org.freedesktop.DBus -> destination=:1.0 serial=3 reply_serial=2 array [ string "org.freedesktop.DBus" string "org.gtk.GLib.PACRunner" string "org.freedesktop.portal.Desktop" <-- NEED THIS string "org.freedesktop.portal.Documents" string "org.freedesktop.impl.portal.PermissionStore" string "org.freedesktop.impl.portal.desktop.wlr" <-- NEED THIS ]
(In reply to Jan Beich from comment #7) > pulsaudio via alsa-plugins bloat is attributed to lack of subpackaging To be fixed by https://reviews.freebsd.org/D43667