Enable PipeWire support on Linux builds

[vchernin]

Is your suggestion related to a problem? Please describe.

Element desktop on linux is currently unable to screen share on wayland in either an officially supported deb or an unofficial flatpak. For both package formats, the functionality could be made to work if element's linux desktop app is shipped with pipewire support. Wayland is default now in most linux distros which use gnome, which includes ubuntu 21.04, any recent fedora, debian 10, rhel/centos/rocky/alma 8, manjaro, and many others.

Describe the solution you'd like.

Build/ship element desktop linux builds with pipewire enabled, using upstream provided flags. This likely means explictly setting rtc_use_pipewire=true and use_sysroot=true when building element.

Describe alternatives you've considered.

A workaround is running element in chrome/chromium with a pipewire flag manually enabled. This works fairly well even when chromium is in a flatpak and a wayland session is used.

Additional context

Considering upstream chromium on wayland can be made to work by enabling one flag (not changing anything in element itself), and that element ships the most recent electron version (v12 as of writing), this hopefully should only be a fairly trivial change. Enabling pipewire support should not regress current screen sharing functionality on linux or elsewhere.

Flags that would need to be enabled in element's builds to enable pipewire as an option:
Per this comment element builds likely need:
rtc_use_pipewire=true

Per this comment element builds need:
use_sysroot=true

Sidenote, per upstream chromium, it seems rtc_use_pipewire=true should automatically be enabled if use_sysroot=true is enabled on linux. Still, it is probably easiest to just ensure both flags mentioned here are enabled.

Finally, once element is building with pipewire properly enabled (via the above 2 flags set), you can fully activate pipewire in element by starting it with the command line argument:
--enable-features=WebRTCPipeWireCapturer
For flatpak run:
flatpak run im.riot.Riot --enable-features=WebRTCPipeWireCapturer

To compare to another chromium app that is known to work on wayland (and even as a flatpak), try downloading chromium from flathub, enabling enable-webrtc-pipewire-capturer in chrome://flags, restarting chromium, and opening app.element.io in chromium. Then join a room with at least 3 members, and start a video call and then try to screen share from within element's jitsi widget.

[jryans]

Flags that would need to be enabled in element's builds to enable pipewire as an option:
Per this comment element builds likely need:
rtc_use_pipewire=true

Per this comment element builds need:
use_sysroot=true

This seems to suggest a custom build of Electron is needed at the moment. We don't currently build Electron ourselves, and I think it's unlikely we would take on that burden.

We may be a bit stuck here until it's compiled by default in Electron and can be toggled at runtime from the official builds.

[vchernin]

@jryans Does element use official electron builds, or are the builds sourced from elsewhere? (Edit: I see now the mention of Element potentially using a runtime toggle in the official builds, meaning to me Element is on official Electron).

I ask as this comment says that official electron builds set rtc_use_pipewire=true by default, which if element built with, would theoretically solve this issue. However, they also say that some builds set use_sysroot=false which could disable pipewire support. See this chromium config file which disables rtc_use_pipewire=true if use_sysroot=false.

I might open an issue in electron's github page to get this resolved upstream. Are there any other changes that element makes to electron that could possibly effect pipewire screen sharing on linux?

[vchernin]

I've opened an upstream feature request to build Electron with PipeWire by default. Solving the upstream issue would theoretically solve this Element issue, but does not necessarily mean PipeWire will work for Element by default, currently you would still need --enable-features=WebRTCPipeWireCapturer (see the upstream issue for more info).

[jryans]

Does element use official electron builds, or are the builds sourced from elsewhere?

Yes, we use the official Electron builds.

Are there any other changes that element makes to electron that could possibly effect pipewire screen sharing on linux?

Well, I can't think of any at the moment... I believe we're leaving all of that to the platform.

[vchernin]

Curiously the Jitsi Meet desktop app, which also uses Electron 12 official builds, actually can screen share on wayland with PipeWire. This leads to me to believe that upstream Electron does actually build with the correct flags, meaning my upstream bug report won't solve this Element issue. If Electron is indeed shipping the flags needed that means there is something else that stops the embedded Jitsi in Element from working correctly.

Is there any way I could open an arbitrary site like this WebRTC test page in Element?

I got a log with the Chromium console. This log is produced when clicking screen share in Element Jitsi in the official deb on Ubuntu 21.04 or the unofficial Flatpak on Fedora 34 silverblue. Note this is when --enable-features=WebRTCPipeWireCapturer is passed at runtime.

The log does seem to go in circles, but I did find this reoccuring line:

Logger.js:154 2021-05-12T18:41:54.675Z [features/desktop-picker] Called JitsiMeetElectron.obtainDesktopStreams but it is not defined

I don't see such an error in Chromium (where this feature works correctly). The Jitsi Meet Electron Flatpak app also doesn't show give that error (it works correctly).

Perhaps the issue here is Element not packaging Jitsi correctly in Electron? Perhaps Jitsi Meet Electron will has good examples since PipeWire works there.

Visually this error always goes to this infinite loading menu whenever I click screen sharing in Element's Jitsi integration.

[SimonBrandner]

This is #4880

[t3chguy]

Is there any way I could open an arbitrary site like this WebRTC test page in Element?

Not without building it yourself

---

As @SimonBrandner says above, the obtainDesktopStreams log is an Electron + Jitsi specific issue, which Jitsi Meet Electron gets around by disabling some security features which Element cannot do. Jitsi Meet isn't packaged in Element, its merely an iframe just like all other Matrix Widgets.

[SimonBrandner]

Does this whole issue originate from this bug?

[SimonBrandner]

Jitsi Meet Electron gets around by disabling some security features

They could actually switch to using a context bridge and then they'd have no security issues.

[vchernin]

I can confirm screen sharing also doesn't work on Linux x11, so yes it looks like this whole issue originates from element-hq/element-desktop#683.
I somehow remember Jitsi working in Element on x11 but I must have been using Chromium.

On the bright side this means there is likely no upstream Electron bug, so when element-hq/element-desktop#683 is fixed Element Wayland screen sharing should work. However, it is possible that when element-hq/element-desktop#683 is fixed, Wayland screen sharing in Element won't work, so this issue might be reopened in the future.

Closing since this issue is basically a duplicate for now.