Propositions to move forward with PipeWire portals

[tytan652]

Move PipeWire logic in-tree

Reminder:

• Both PipeWire and WirePlumber have modular architecture
• WirePlumber is the main session manager implementation
  • pipewire-media-session is just an example implementation that is no longer meant for production use since WirePlumber has been endorsed

Access module

PipeWire has in its tree a module to set pipewire.access to "portal" if the PID that created core is xdg-desktop-portal's.

Which allow the session manager to filter them and manage those core permission with the permission store.

While the necessity of moving it seems low, I still propose to move it in-tree to reduce fragmentation of xdg-desktop-portal logic across repos.

Implementation detail

The in-tree module will be built and installed if the system PipeWire is version 1.3.81 or later.
Earlier version does not allow the original module to be disabled through a drop-in configuration file.

Permission management

WirePlumber has in its tree:

• A feature as a C module to handle the permission store
• A feature as a Lua script to handle xdp-desktop-portal cores device node permissions

I propose to implement a module to replace those features with one in-tree C module.

This would allow to change how some portals without having to wait for a WirePlumber release and the needed change to its features.

Some desired portal feature are likely to need to add logic to this module.

Implementation detail

Property keys like pipewire.access.portal.app_id would be replaced with by one using "xdg-desktop-portal" (e.g. pipewire.access.xdg-desktop-portal.app_id), this would avoid to conflict with any assumptions that PipeWire made (e.g. set a app id on a core not created by xdg-desktop-portal).

Replace media.role

xdg-desktop-portal relies on this property key to identify Camera.

The main issue is that the real usage of the key by WirePlumber is completely different.

• https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/455#note_1647238
• https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/489#note_2022731

I propose to completely replace our usage of this key.
By using media.class alongside a new boolean key meant to indicate that the node representing a device is user facing.

If the key is unset or set to false, the device is not to be shown to the user.

A user-facing:

• Video/Source can be a camera or a capture card
• Audio/Sink can be speakers or headphones
• Audio/Source can be a microphone, an instrument or the audio stream of a capture card

It can be observed that this way we also avoid any struggle about applying a term that do not perfectly match the device behind the node (e.g. "Camera" on capture card or "Microphone" on a digital instrument).

Enable multiple way to get a core

OpenPipeWireRemote

The main (and only for now) way to get a permission-controlled PipeWire core in a sandbox.

The given core has pipewire.access set to "portal" (or "xdg-desktop-portal") and xdg-desktop-portal has set the app id and the media role to camera if Camera portal.

Flatpak (draft idea)

The idea is for Flatpak (or PipeWire) to have module that mark with the app id (e.g. pipewire.access.flatpak.app_id) and maybe the instance id any core created through PipeWire socket with Flatpak security context.

xdg-desktop-portal WirePlumber module would manage those core permission and use at least pipewire.access.flatpak.app_id to apply the matching permission for device nodes.

Other sandbox system

Like xdg-desktop-portal has specific code to handle Snap app information, those other system needs would need to the same as Flatpak to have their own access type and make the xdg-desktop-portal WirePlumber module handle it.

---

TODOs:

• Implement PipeWire and WirePlumber modules in-tree
• Add the new "user facing" boolean key to PipeWire and its device modules to replace xdp media.role usage
• Document xdg-desktop-portal behavior

MAYBEs:

• Add support for Flatpak PipeWire security-context socket (alongside OpenPipeWireRemote)

[tytan652]

The more I think about it the less I feel like that Flatpak should provide it's own way to gave a PipeWire core but xdp should propose a more portal-agnostic method to get one (works for any portal thanks to permission control).

Otherwise we would have every sandbox system implementing their own core addition where we could just provide one that likely fits them all.