-
Notifications
You must be signed in to change notification settings - Fork 54
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, but we have no development timeline. See https://github.com/emersion/xdg-desktop-portal-wlr/issues/107.
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, only with v5.10 and newer. Prior to Zoom v5.10, they used a Gnome specific API that this project does not seek to emulate.
However, to use screensharing with Zoom v5.10+, you will need to launch Zoom
with XDG_CURRENT_DESKTOP=GNOME to trick Zoom into believing it is running
on Gnome, which enables Zoom's desktop-agnostic implementation that uses the
xdg-desktop-portal screencast API.
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. Look at troubleshooting checklist first.
Come see us in #sway on libera.chat if you think you have an issue beyond what is covered there.
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.
If you want to run xdpw manually (eg. for debugging reasons) please note, that
it is usually installed into /usr/lib, /usr/libexec or a similar directory
which is not in the usual $PATH. Please query your package manager, if in doubt.
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