xdg-desktop-portal
xdg-desktop-portal copied to clipboard
flatpak
device: Add OpenPipeWireRemote() method
It works very similarly to the same-named method of the Camera portal, except it receives a list of devices to access.
This new method returns an error if an unsupported device is requested, or if the app doesn't have permission to access any of the requested devices.
I couldn't add the tests since they rely on libportal implementing this, but it's not there yet. I'll add the corresponding code as a separate step after working on libportal's implementation.
@wtay hey, i've opened the corresponding media-session MR relative to this portal: https://gitlab.freedesktop.org/pipewire/media-session/-/merge_requests/25
I'd love to hear your thoughts on this portal
Following IRC discussions with Wim, I'm changing this PR to add a new method to the Devices portal instead. The reasoning behind this shift in direction is that it is better to open one single PipeWire remote with different media roles, instead of one per media role. Things like GStreamer will benefit from it.
The Camera portal is made somewhat useless with this change, but I didn't touch it for now. At some point, it'll be interesting for us to retire the Camera portal.
Following IRC discussions with Wim, I'm changing this PR to add a new method to the Devices portal instead. The reasoning behind this shift in direction is that it is better to open one single PipeWire remote with different media roles, instead of one per media role. Things like GStreamer will benefit from it.
I've been also thinking it's a good idea to explore a "common" portal for opening PipeWire remotes to not have to use multiple PipeWire remotes for different. I'm not sure about placing it inside the Device portal though, it's something that has been used by e.g. pulseaudio to check permissions from outside the sandbox IIRC. Might be something we can eventually remove, so I think adding a org.freedesktop.portal.Media or something is better way.
The Camera portal is made somewhat useless with this change, but I didn't touch it for now. At some point, it'll be interesting for us to retire the Camera portal.
Yes, makes sense to deprecate the camera portal if we add something that can handle both camera and other media roles.
I'm not sure about placing it inside the Device portal though, it's something that has been used by e.g. pulseaudio to check permissions from outside the sandbox
This pull request doesn't interfere with PulseAudio in any way, applications that need device access should use the AccessDevice() method exactly like they used to. This pull request merely adds a way to grab a filtered PipeWire fd for cameras, speakers, and / or microphones.
Hmm. I see what you mean, the client would take over "ask for access" action from the camera portal/pulseaudio, by doing it "manually" via AccessDevice. Yea, maybe this is the best way.
Maybe we should add properties for whether a certain device class exists on the system, as currently handled by the camera portal. Quoting the Camera pull request:
In order to allow an application to only request camera permission would there be any cameras available, there is a IsCameraPresent boolean property that will expose whether there are any cameras available at all.
Good idea. That would translate to adding IsCameraPresent, IsSpeakerPresent, and IsMicrophonePresent here. I can add that. Should we change these property names?
Added these properties! Most of this code was adapted from the Camera portal
How will monitor nodes be handled in this proposal? IMO the capability to output to an audio device and to capture output from an audio device should be separate.
How will monitor nodes be handled in this proposal? IMO the capability to output to an audio device and to capture output from an audio device should be separate.
This portal (with this MR) sets the PipeWire "media role" to either "Speaker", "Microphone", or "Camera". It is then up to PipeWire to determine whether a moniter output device falls into any of these categories. I would assume it shouldn't. @wtay is this the case?
Whether we should add monitor devices here, I'm not sure. Some how we need a portal to allow "arbitrary" PipeWire routing e.g. for DAW:s, which the "monitor" capture somewhat falls into, but not sure how that permission model should look like.
Apparently in PipeWire output and monitor are two different port types on the same node/device. It should be possible to separate monitor ports into a separate category and change PipeWire and the media session manager to perform access control on port-level granularity instead of device/node-level. (Currently the function responsible for checking permission to create a link between two ports is a stub that always return success).
Currently the function responsible for checking permission to create a link between two ports works on the device/node-granularity level and is a stub that always return success)
It's not really a problem, the port permissions are first checked when a client wants to create a link and the client just can't make the link.
It is usually the session manager that makes the links for clients, and it usually has all permissions anyway. It is the session manager that should deny creating links between a monitor port and the client stream when it has no permission.
@GeorgesStavracas @jadahl just a reminder to look into this one soon if possible :)
Converting to draft until the following is done:
- Reconsider permissions naming; specifically, "speakers"
- Add support for "monitor" permission type
I've been looking in to the camera portal API and I was a bit surprised by the all-or-nothing character of a security feature and that seems to be replicated here. I expected the permissions to be granted on a per device basis rather than per category of device.
That would translate to adding IsCameraPresent, IsSpeakerPresent, and IsMicrophonePresent here. I can add that. Should we change these property names?
How about using more general names, "audio input" and "audio output"? The portal has no idea what devices are actually connected to the audio interface. Does it make sense to ask permission to use speakers when only headphones are connected? For all we know the user could be setting up an audio effects loop with a DAW and a guitar pedal without anybody hearing the audio.
Add support for "monitor" permission type
The word "monitor" without further context is ambiguous. A computer screen is a "monitor", which could be confused with the ScreenCast portal. Studio speakers are also called "monitors". But I don't think either of these meanings are what you're talking about.
I've been looking in to the camera portal API and I was a bit surprised by the all-or-nothing character of a security feature and that seems to be replicated here. I expected the permissions to be granted on a per device basis rather than per category of device.
The portal does not handle permissions, It only signals to the session manager to enforce permissions on 'camera' devices. Using the permission store you get per device permissions (and new devices that pop up later also get the right permissions).
Should there be a fallback mechanism for Flatpaks to access the PipeWire socket in case this method isn't available? Even after this API is introduced, PipeWire-using apps would have to keep filesystem=xdg-run/pipewire-0 in their manifests for older xdg-desktop-portal versions.
I imagine a similar fallback to wayland and fallback-x11 which allows Wayland supporting apps to have safer permissions on Wayland desktops, while still working on X11.
Or is fallback unnecessary given most distros using PipeWire would typically have newer xdg-desktop-portal? Also, keeping filesystem=xdg-run/pipewire-0 is not the worst sandbox hole.
Add support for "monitor" permission type
The word "monitor" without further context is ambiguous. A computer screen is a "monitor", which could be confused with the ScreenCast portal. Studio speakers are also called "monitors". But I don't think either of these meanings are what you're talking about.
The most coherent term I can come up with for this case is just an "Audio Monitor", to fit in with "Audio Input" and "Audio Output". People don't refer to their headphones as "speakers" so referring it to the more ambigious "Audio Output" seems like it makes more sense to me. For microphones "Audio Input" makes more sense, especially if this portal would also be used for capturing MIDI devices. Windows and MacOS already use the terms "(Sound) Input/Output" for users. An alternative would be "Playback/Recording Device", but not all playback and captures are devices nor does this term have consistency for "Monitor Device".
Should there be a fallback mechanism for Flatpaks to access the PipeWire socket in case this method isn't available? Even after this API is introduced, PipeWire-using apps would have to keep
filesystem=xdg-run/pipewire-0in their manifests for older xdg-desktop-portal versions.
A socket would be useful, although I would hope Pipewire aware applications would get to using the portals soon enough.
After some IRC discussion, we'll need wireplumber to set up "roles" or something for the missing device classes. A starting point for this is https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/455.
Something that came to mind during a related discussion: might want to create a new interface entry point, e.g. org.freedesktop.portal.Devices to avoid confusion about the existing method that's useless from sandboxed apps.