[snap] (experimental) pipewire support not available

[Alberto Donato]

I'm using the chromium snap (currently 77.0.3865.120, rev 899), it's not possible to enable experimental support for pipewire, as the toggle doesn't show up in chrome://flags.

It would be nice to have chromium compiled with pipewire support, to enable screensharing in Hangouts and similar apps.

[Olivier Tilloy (osomon)]

In third_party/webrtc/webrtc.gni¹:

  # Set this to use PipeWire on the Wayland display server.
  # By default it's only enabled on desktop Linux (excludes ChromeOS) and
  # only when using the sysroot as PipeWire is not available in older and
  # supported Ubuntu and Debian distributions.
  rtc_use_pipewire = is_desktop_linux && use_sysroot

use_sysroot is set to false in snap builds, so rtc_use_pipewire would need to be explicitly set to true. This might require additional build/runtime deps (assuming they are available in Ubuntu 18.04, which is used to build the chromium snaps).

¹ https://cs.chromium.org/chromium/src/third_party/webrtc/webrtc.gni?type=cs&q=rtc_use_pipewire&sq=package:chromium&g=0&l=115

[Olivier Tilloy (osomon)]

See also the announcement on the chromium-packagers mailing list: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/oEtkQUfwcus

[Martin Vysny (vyzivus)]

Starting from Ubuntu 21.04 the pipewire libs are bundled in Ubuntu itself, to allow screen sharing over webrtc. This allows Firefox to cast screen properly, which is great :)

However, since the Chromium snap is missing the pipewire support (currently 90.0.4430.85), it's not possible to set the flag chrome://flags/#enable-webrtc-pipewire-capturer to true, which effectively disables screen sharing on Chromium.

[Martin Vysny (vyzivus)]

[continuing]

This is bad, since Ubuntu 21.04 switches from Xorg to Wayland by default which effectively disables screen sharing on Chromium. User needs to go back to Xorg to enable screen sharing on Chromium, which is a bit of a pity since pipewire is already in place and ready to be used.

[Olivier Tilloy (osomon)]

Working on this in a branch: https://code.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/+ref/enable-pipewire

[Olivier Tilloy (osomon)]

My first shot at it allows me to enable pipewire support in chrome://flags, but makes the browser crash when actually trying to share a window in a WebRTC application (e.g. meet.jit.si). I'm seeing the following messages on stderr with verbose logging:

[71968:71968:0426/182013.480562:INFO:base_capturer_pipewire.cc(914)] Created proxy for the screen cast portal.
[71968:71968:0426/182013.480603:INFO:base_capturer_pipewire.cc(952)] Screen cast session requested.
[71968:71968:0426/182013.500256:INFO:base_capturer_pipewire.cc(977)] Initializing the screen cast session.
[71968:71968:0426/182013.500274:INFO:base_capturer_pipewire.cc(992)] Subscribing to the screen cast session.
[71968:71968:0426/182013.500648:INFO:base_capturer_pipewire.cc(1007)] Received response for the screen cast session subscription.
[71968:71968:0426/182013.500685:INFO:base_capturer_pipewire.cc(1047)] Requesting sources from the screen cast session.
[71968:71968:0426/182013.501519:INFO:base_capturer_pipewire.cc(1073)] Sources requested from the screen cast session.
[71968:71968:0426/182013.501530:INFO:base_capturer_pipewire.cc(1088)] Subscribed to sources signal.
[71968:71968:0426/182013.501759:INFO:base_capturer_pipewire.cc(1103)] Received sources signal from session.
[71968:71968:0426/182013.501780:INFO:base_capturer_pipewire.cc(1133)] Starting the screen cast session.
[71968:71968:0426/182013.502497:INFO:base_capturer_pipewire.cc(1160)] Initializing the start of the screen cast session.
[71968:71968:0426/182013.502507:INFO:base_capturer_pipewire.cc(1176)] Subscribed to the start signal.
…
[71968:71968:0426/182020.558054:INFO:base_capturer_pipewire.cc(1191)] Start signal received.
[71968:71968:0426/182020.558108:INFO:base_capturer_pipewire.cc(1236)] Opening the PipeWire remote.
[E][pipewire.c:343 add_interface()] can't get Spa:Pointer:Interface:Log interface -2
[E][pipewire.c:343 add_interface()] can't get Spa:Pointer:Interface:CPU interface -2
[E][loop.c:85 pw_loop_new()] loop 0x55c5b2b74ee0: can't make support.system handle: No such file or directory
…
Erreur de segmentation (core dumped)

[Olivier Tilloy (osomon)]

More info with PIPEWIRE_DEBUG=4:

[D][pipewire.c:257 pw_load_spa_handle()] load lib:'support/libspa-support' factory-name:'support.log'
[D][pipewire.c:125 open_plugin()] can't load /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so: /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so: cannot open shared object file: No such file or directory
[E][pipewire.c:343 add_interface()] can't get Spa:Pointer:Interface:Log interface -2
[D][pipewire.c:257 pw_load_spa_handle()] load lib:'support/libspa-support' factory-name:'support.cpu'
[D][pipewire.c:125 open_plugin()] can't load /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so: /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so: cannot open shared object file: No such file or directory
[E][pipewire.c:343 add_interface()] can't get Spa:Pointer:Interface:CPU interface -2
[I][pipewire.c:550 pw_init()] version 0.3.26
[D][thread-loop.c:115 loop_new()] thread-loop 0x55946af45600: new
[D][pipewire.c:257 pw_load_spa_handle()] load lib:'support/libspa-support' factory-name:'support.system'
[D][pipewire.c:125 open_plugin()] can't load /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so: /usr/lib/x86_64-linux-gnu/spa-0.2/support/libspa-support.so: cannot open shared object file: No such file or directory
[E][loop.c:85 pw_loop_new()] loop 0x55946af45700: can't make support.system handle: No such file or directory

[Olivier Tilloy (osomon)]

Setting SPA_PLUGIN_DIR to /snap/chromium/current/usr/lib/x86_64-linux-gnu/spa-0.2 makes the crash go away, but screen sharing still doesn't work:

[W][000040760.557582][conf.c:243 conf_load()] config 0x559d4c0175d0: error loading config '/etc/pipewire/client.conf': Permission denied
[W][000040760.557598][context.c:178 try_load_conf()] context 0x559d4cd928a0: can't load config client.conf: Permission denied
[E][000040760.557605][context.c:242 pw_context_new()] context 0x559d4cd928a0: can't load config client.conf: Success
[77299:77299:0426/184052.084211:ERROR:base_capturer_pipewire.cc(538)] Failed to create PipeWire context

[Olivier Tilloy (osomon)]

More environment variables are needed to adjust paths for pipewire:

    SPA_PLUGIN_DIR: $SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/spa-0.2
    PIPEWIRE_CONFIG_NAME: $SNAP/etc/pipewire/pipewire.conf
    PIPEWIRE_MODULE_DIR: $SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/pipewire-0.3

Now seeing an apparmor denial:

[W][000041415.865159][module-portal.c:147 on_portal_pid_received()] Failed to receive portal pid: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.580" (uid=1000 pid=80555 comm="/snap/chromium/x1/usr/lib/chromium-browser/chrome " label="snap.chromium.chromium (enforce)") interface="org.freedesktop.DBus" member="GetConnectionUnixProcessID" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)

[Olivier Tilloy (osomon)]

The denial goes away if I manually edit the snapd-generated apparmor profile to add the following rule:

  dbus (send)
    bus=session
    path=/
    interface=org.freedesktop.DBus
    member=GetConnectionUnixProcessID
    peer=(name=org.freedesktop.DBus, label=unconfined),

[Olivier Tilloy (osomon)]

… but screen sharing still doesn't work. This requires further investigation.

[Marco Trevisan (Treviño) (3v1n0)]

Isn't better to use bindings now instead of those env variables?
As they tend to be a bit fragile...

[Adolfo Jayme Barrientos (fitojb)]

This issue bit me last month when conducting a (supervised — I went full Bad-luck Brian on that one, lol) online class with my students on Google Meet; they could only see black whenever I shared something other than Chromium’s window. Luckily I was able to display all my material on browser tabs, so that was a workaround! But still…

[Olivier Tilloy (osomon)]

> Isn't better to use bindings now instead of those env variables?
> As they tend to be a bit fragile...

I assume you mean layouts?
As long as upstream doesn't remove the ability to customize config/plugins directories, this should be functionally equivalent to using layouts. I don't have a strong opinion on the topic though, if you have good arguments in favour of layouts, I'm open to using them (the chromium snap already has one layout definition).

[Olivier Tilloy (osomon)]

Relevant output from pw-dump when sharing the entire screen (which remains black). The interesting bit is ["state": "suspended"]:

  {
    "id": 34,
    "type": "PipeWire:Interface:Client",
    "version": 3,
    "permissions": [ "r", "w", "x", "m" ],
    "info": {
      "change-mask": [ "props" ],
      "props": {
        "pipewire.protocol": "protocol-native",
        "pipewire.sec.pid": 5394,
        "pipewire.sec.uid": 1000,
        "pipewire.sec.gid": 1000,
        "pipewire.sec.label": "unconfined",
        "module.id": 2,
        "object.id": 34,
        "log.level": 0,
        "clock.power-of-two-quantum": true,
        "default.clock.rate": 48000,
        "default.clock.quantum": 1024,
        "default.clock.min-quantum": 32,
        "default.clock.max-quantum": 8192,
        "default.video.width": 640,
        "default.video.height": 480,
        "default.video.rate.num": 25,
        "default.video.rate.denom": 1,
        "link.max-buffers": 64,
        "mem.warn-mlock": false,
        "mem.allow-mlock": true,
        "cpu.max-align": 32,
        "application.name": "gnome-shell",
        "application.process.binary": "gnome-shell",
        "application.language": "fr_FR.UTF-8",
        "application.process.id": 5394,
        "application.process.user": "osomon",
        "application.process.host": "dantian",
        "window.x11.display": ":0",
        "core.version": "0.3.24",
        "core.name": "pipewire-osomon-5394",
        "pipewire.access": "unrestricted"
      }
    }
  },
  {
    "id": 33,
    "type": "PipeWire:Interface:Node",
    "version": 3,
    "permissions": [ "r", "w", "x", "m" ],
    "info": {
      "max-input-ports": 0,
      "max-output-ports": 1,
      "change-mask": [ "input-ports", "output-ports", "state", "props", "params" ],
      "n-input-ports": 0,
      "n-output-ports": 1,
      "state": "suspended",
      "error": null,
      "props": {
        "media.name": "meta-screen-cast-src",
        "stream.is-live": true,
        "node.name": "gnome-shell",
        "node.driver": true,
        "media.class": "Stream/Output/Video",
        "client.id": 34,
        "object.id": 33
      },
      "params": {
      }
    }
  },
  {
    "id": 35,
    "type": "PipeWire:Interface:Port",
    "version": 3,
    "permissions": [ "r", "w", "x", "m" ],
    "info": {
      "direction": "output",
      "change-mask": [ "props", "params" ],
      "props": {
        "port.id": 0,
        "port.direction": "out",
        "port.name": "out_0",
        "node.id": 33,
        "object.id": 35
      },
      "params": {
        "EnumFormat": [
          {
            "mediaType": "video",
            "mediaSubtype": "raw",
            "format": "BGRx",
            "size": { "width": 1920, "height": 1080 },
            "framerate": { "num": 0, "denom": 1 },
            "maxFramerate": { "default": { "num": 7864385, "denom": 131072 }, "min": { "num": 1, "denom": 1 }, "max": { "num": 7864385, "denom": 131072 } }
          }
        ],
        "Meta": [
          {
            "type": "Busy",
            "size": 8
          }
        ],
        "IO": [
          {
            "id": "Buffers",
            "size": 8
          }
        ],
  ...

[Julian Alarcon (julian-alarcon)]

This bug report could be related

"Upgrade pipewire from 0.2 to 0.3 for chromium/webrtc"
https://bugs.chromium.org/p/chromium/issues/detail?id=1146942

[Olivier Tilloy (osomon)]

Progress: I managed to get screen capture to partially work by rebasing my test snap on chromium 96.0.4664.18, which contains the following commit: https://source.chromium.org/chromium/_/webrtc/src.git/+/593b4d550d5569997c65dc1226238da04d4ea61a.

This works only partially because it allows sharing a selected window, or a selected browser tab, but not the full screen (in that last case the capture is entirely black except for the mouse cursor).

[Olivier Tilloy (osomon)]

Fixed with https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=9bb2debda802087e3910a720dc63172f1471ed09.

[Robie Basak (racb)]

So I have this sort of working on my machine that's running Impish. The only annoying thing is that the window selector pop-up appears twice, and the second one seems superfluous (I have to hit Cancel on it).

On a freshly installed Jammy machine, I had to enable chrome://flags/#enable-webrtc-pipewire-capturer but even then it doesn't work. When I try to cast, it seems to start and immediately fail, and I never get a popup. When the flag is not enabled, it casts a blank window with just a mouse pointer. So the flag is doing something, but doesn't seem to be functional on Jammy.

[Robie Basak (racb)]

In both cases I'm running:

installed: 98.0.4758.9 (1868) 154MB -

[Alberto Donato (ack)]

I have a slightly different issue on Impish, with 97.0.4692.99 (1878):

With the pipewire flag enabled, I do get the popup, I can select a window but then nothing happens, and the initial popup doesn't ever close, I have to cancel the screen share.

[Olivier Tilloy (osomon)]

Alberto, could it be the same issue that Robie is describing, that the window selector pop-up appears twice? I'm seeing this too (on Impish), although screen sharing only works if I confirm the second popup, not if I cancel it.

[Olivier Tilloy (osomon)]

Robie: I just tested on jammy, and I'm seeing something different: with the flag enabled, screen sharing works (although I do get the window selection pop-up displayed twice, same as on impish). Without the flag, I'm seeing a black screen with the mouse cursor, like you do.

Could you test again with the latest chromium from the stable channel, on an up-to-date jammy, and let me know if your observations are consistent with mine?

[Alberto Donato (ack)]

Olivier, if I click "share a window" the following happens:

 - the in-app "Share an application window" popup appears (nothing in it)
 - the standalone "Screen share" popup appears"
 - I select a (wayland-based) window, click ok
 - the original "Share an application window" popup is still there, still empty, "Share" button is disabled, I can only cancel

[Alberto Donato (ack)]

I just tested now sharing the whole screen, in that case after I select the display on the second popup, I see the preview on the first one, select it, a new popup appears and if I select the screen again then it does work.

This trick only seems to work for the whole screen thoough, not a single window.