-
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. It would take significant work in wlroots, and likely a new protocol, to make this possible. A second rendering pass would be required, which would significantly reduce wlroots performance, so this may not be implemented any time soon (or ever).
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 the appropriate chrome://flags flag (chromium only)
- You haven't started xdpw with the appropriate pixelformat workaround CLI option (to be fixed in the future)
- You haven't set XDG_SESSION_TYPE=wayland before starting your browser
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.
You need to run xdpw like this:
/usr/lib/xdg-desktop-portal -r & /usr/lib/xdg-desktop-portal-wlr [OPTION...]
because xdg-desktop-portal needs to be aware of the implementation instance in
order to correctly advertise certain properties, like whether or not xdpw
supports window sharing (it doesn't) or what cursor modes are supported (none
and embedded, but not metadata). The -r flag on xdg-desktop-portal is meant
to "replace a running instance", and will use the new one we are starting after
the ampersand. Make sure you kill existing instances first before doing this.
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 (where you should replace OPTIONS
with the flags you need):
[Service]
ExecStart=
ExecStart=/usr/lib/xdg-desktop-portal-wlr OPTIONS...
Changes made in this way are easily forgotten about, and flags are subject to 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