-
Notifications
You must be signed in to change notification settings - Fork 61
Screencast Compatibility
This guide contains information on applications compatible with xdg-desktop-portal-wlr. If screencasting works for you in some applications, but not others, please review this guide.
WebRTC is a protocol and specification for real-time communication, but it is also a shared codebase and a set of APIs used by Firefox and Chromium to provide screen capture and casting functionality. You can test this functionality using the getUserMedia Test Page over on Mozilla's GitHub.
WebRTC contains support for xdg-desktop-portal based screen casting, but
requires a special build flag RTC_USE_PIPEWIRE=true
in order to be included. Some distros build their browsers with this
flag and some do not.
No matter what browser you are using, the WebRTC code will check that the
environment variable XDG_SESSION_TYPE=wayland is set
in order to use xdg-desktop-portal.
| OS | Package Name | Supported? | Notes |
|---|---|---|---|
| Arch | chromium | Yes | Tested version 81.0.4044.122, requires a feature toggle set in chrome://flags search for pipewire to find it. Requires libpipewire02 installed. |
| firefox-wayland-hg | Yes | Minimal patch against hg trunk. Daily builds available from chaotic-aur | |
| fedora-firefox-wayland-bin | Yes | Tested version 75.0, Present in AUR only, takes the binary Firefox package from Fedora and repacks it for Arch | |
| firefox | Yes | Works out of the box since package version 84.0-1. | |
| Alpine | chromium | No | APKBUILD doesn't contain RTC_USE_PIPEWIRE=true flag |
| firefox | Yes | ||
| Fedora | chromium | Yes | Build Flag |
| firefox | Yes | Pipewire 0.3 Patch | |
| Gentoo | firefox | Yes |
Tested using:
Requires the "screencast" USE-flag to be set for Firefox, which is still masked:
mkdir -p /etc/portage/profile/package.use.mask && echo 'www-client/firefox -screencast' >> /etc/portage/profile/package.use.mask/firefox
mkdir -p /etc/portage/package.use && echo 'www-client/firefox screencast' >> /etc/portage/package.use/firefox
|
| chromium | Partial |
Tested using:
Gentoo does not enable any Pipewire support in its Chromium package by default but the user can enable it themselves by setting EXTRA_GN='rtc_use_pipewire=true' via portage's package.env. Chromium is only compatible with media-video/pipewire:0/0.2 which cannot be co-installed with media-video/pipewire:0/0.3.
|
|
| OpenSuse (Tumbleweed) | chromium | Yes |
Pipewire 0.3 Patch
A libpipewire0_2 package containing the Pipewire 0.2 client library is also available, so that binaries like Chrome and Electron apps that can't be patched to use Pipewire 0.3 can still work.
|
| firefox | Yes | Pipewire 0.3 Patch | |
| Debian | chromium | Not yet | Debian now ships pipewire 0.3 in unstable, meaning only a patch to Chromium is required. Relevant issue |
| firefox | Not yet | Debian now ships pipewire 0.3 in unstable, meaning only a patch to FF is required. Relevant issue |
While Electron is built based on chromium, it does not build with the
RTC_USE_PIPEWIRE=true flag set, so it currently does not work
on any distro that we are aware of. There is an effort to build
electron-ozone based on chromium-ozone, which will be a Wayland-native
version of electron. The most recent builds of electron-ozone
include this flag
, but they are currently very unstable and will not be usable for most
mainstream Electron apps (VSCode, MS Teams, Slack, etc.)
source: https://gitlab.gnome.org/feaneron/obs-xdg-portal/
xdg-desktop-portal-wlr should be perfectly compatible with obs-xdg-portal,
but you should probably be using the wlrobs plugin instead. If you get
errors regarding cursor modes, it is likely that you are not letting
xdg-desktop-portal-wlr start automatically, or you are not starting it
correctly with
/usr/lib/xdg-desktop-portal -r & /usr/lib/xdg-desktop-portal-wlr
source: https://github.com/benzea/gnome-network-displays
Unknown, needs testing.
source: https://gitlab.gnome.org/snippets/19
This is probably the simplest/most minimal test to ensure that xdg-desktop-portal-wlr screencasting is working correctly. If you're having issues elsewhere, try this first.