-
Notifications
You must be signed in to change notification settings - Fork 63
xdpw is short for the name of this project, xdg-desktop-portal-wlr. This project seeks to add support for the screenshot, screencast, and possibly remote-desktop xdg-desktop-portal interfaces for wlroots based compositors.
They were originally designed to offer access to system resources inside of flatpak sandboxes. More recently, large compositors have influenced many software makers to adopt these portals as standard mechanisms for screenshot and screencast functionalities in Wayland.
PipeWire is a server and user space API to deal with multimedia pipelines. Its scope is broad, seeking to provide a single mechanism for transporting video and audio streams to and from various applications in a unified fashion.
For our purposes, it is the specified standard transport mechanism for the xdg-desktop-portal screencast API.
PipeWire 0.3 is the latest stable version of the API we use to provide video, so you will need to use a version of the PipeWire daemon greater than 0.3. It is strongly encouraged that you use a version newer than 0.3.3 to avoid an upstream bug that may require you to restart the PipeWire daemon due to intermittent segfaults in the pipewire-media-session child process (caused occasionally when cast clients close their connections).
Many applications still build against PipeWire 0.2. The PipeWire 0.3 daemon is backwards compatible with PipeWire 0.2 consumers, but you may need to install the libraries from PipeWire 0.2 in addition to the full PipeWire 0.3 package. Some distros provide compat packages (libpipewire02 in the case of Arch Linux), to support these older clients.
No, only entire outputs. In the future this may be supported in some capacity by allowing selection of regions of the screen, see https://github.com/emersion/xdg-desktop-portal-wlr/issues/12, but we have no development timeline.
Not yet, no. It will likely never create a single stream that combines all of your outputs, but once we implement better output selection, there is no reason xdpw cannot create multiple simultaneous streams of different outputs.
For the web-based client, yes it will. For the native linux app, no, they use a Gnome specific API that this project does not seek to emulate.
If this is something you care about, please leave feedback for zoom, suggest an improvement for the Linux client, and ask them to support the xdg-desktop-portal screencast API instead of the private Gnome one.
You may want to experiment with something like gnome-dbus-emulation-wlr, but we do not directly support that project.
Hopefully, soon. Electron is based on Chromium, which does support WebRTC screencasting, but special build flags are required to make this possible on Electron itself.
You can read more about this here.
This could be one of many things:
- Your browser isn't built with the RTC_USE_PIPEWIRE=true flag
- You haven't set XDG_SESSION_TYPE=wayland before starting your browser
- You haven't set the appropriate chrome://flags flag (chromium only)
- pipewire-media-session daemon is not installed (some distros package it separately)
-
You haven't started xdpw with the appropriate pixelformat workaround CLI option (to be fixed in the future)- This was fixed in PR #33
You should read the screencast compatibility guide first, specifically the WebRTC section. Come see us in #sway on freenode if you think you have an issue beyond what is covered here.
You don't, "d-bus magic" will start this for you. When a d-bus message is sent to xdg-desktop-portal, it will read a file we install called wlr.portal. That file specifies the name of the interfaces we implement, the d-bus name that we claim, as well as a value for XDG_CURRENT_DESKTOP for which our implementation is appropriate. Additionally, the systemd service file maps our d-bus name to the actual executable, so that d-bus knows what binary to start when xdg-desktop-portal forwards us a request.
As long as you have the systemd service file installed and have the correct value set for XDG_CURRENT_DESKTOP, you don't need to do anything.
Many flags now have corresponding config file entries. This is the preferred way to change settings for xdpw, but for some things like changing the log verbosity, you may still need to use a flag.
xdpw is installed in libexecdir, which is often /usr/lib/ or /usr/libexec/.
This will be distro specific and you should determine where it lives based on
your specific system. The rest of this answer assumes that xdpw is installed at
/usr/lib.
If you'd like to start xdpw from the command line, you can do so with the -r
flag, which will replace any existing running instance with the new one that you
are starting:
/usr/lib/xdg-desktop-portal-wlr -r [OPTIONS...]
You may want to go up a level and replace xdg-desktop-portal too, which is useful if you want to see its logs (with the -v flag). This can show you whether or not xdpw is being recognized by xdp at all:
/usr/lib/xdg-desktop-portal -r -v & /usr/lib/xdg-desktop-portal-wlr -r [OPTIONS...]
You could also create a systemd drop-in config that overrides the ExecStart
setting for xdpw with the command
systemctl --user edit xdg-desktop-portal-wlr.service. An appropriate edit
to add a CLI option might look like this:
[Service]
ExecStart=
ExecStart=/usr/lib/xdg-desktop-portal-wlr [OPTIONS...]
Changes made in this way are easily forgotten about, and flags might change in the future, so this approach could cause issues down the line.
To understand the available options, you can run
/usr/lib/xdg-desktop-portal-wlr --help