[Feature Request]: Build with PipeWire by default in Linux

[vchernin]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Please read this update, it appears this bug isn't actually needed.

WebRTC screen sharing cannot be used on Linux Wayland by default. Electron app developers have to opt to build with the correct Electron flags so users can screen share via PipeWire.

Microsoft Teams, Element and Jitsi Meet do not cherry-pick PipeWire into custom builds, breaking Linux Wayland screen sharing even if a PipeWire runtime flag is used. Element and Jitsi Meet are built with Electron 12, but the issue persists.

Proposed Solution

Configure Electron to build with PipeWire support by default on Linux. This means setting the following by default for Electron Linux builds:

use_sysroot=true

Important: This comment from an Electron Member says the critical PipeWire flag, rtc_use_pipewire=true is already set to true for official Electron builds. However, per upstream Chromium, rtc_use_pipewire=true will only automatically be enabled if use_sysroot=true is enabled on Linux. So potentially only use_sysroot=true is needed, but it might also be necessary to force enable rtc_use_pipewire=true.

Note: Building Electron with PipeWire support is not enough to fully enable PipeWire in Chromium/Electron. Apps built with PipeWire support need to be run with --enable-features=WebRTCPipeWireCapturer for the PipeWire menu to appear when screen sharing. However, this issue is only about building Electron with PipeWire support, not for Electron apps to use PipeWire (see below).

Alternatives Considered

Apps like Slack opt to build with PipeWire support. Because of this, users can run Slack with --enable-features=WebRTCPipeWireCapturer and PipeWire Linux Wayland screen sharing will work.

This issue seemingly cannot be solved in upstream Chromium, since upstream Chromium (i.e. the Google Chrome Linux download) already builds with PipeWire support by default, but unlike Chromium, Electron does not.

Since upstream Chromium already builds with PipeWire support, a workaround is to run an Electron app's web version in Chrome/Chromium with --enable-features=WebRTCPipeWireCapturer.

Additional Information

Wayland is used by default in major Linux distros, including Ubuntu 21.04, any recent Fedora, Debian 10, RHEL/CentOS/Rocky/Alma 8, Manjaro GNOME, and others. This means an increasing amount of users will experience the lack of Wayland screen sharing in Electron apps.

Electron Wayland and PipeWire compatibility was already discussed extensively [1],[2]. However, no bug report was made to build Electron with PipeWire support by default [3].

Note: this PR added support for Electron to run in native Wayland. However, it is not necessary to use native Wayland for PipeWire screen sharing in Chromium/Electron. Whether apps are run in native Wayland has no bearing on this issue.

Note: As mentioned in "Proposed Solution", this issue is only about building Electron with the flag(s) needed for PipeWire to work. This issue is not about running Electron with --enable-features=WebRTCPipeWireCapturer by default, as that change should ideally be done upstream, since Chromium also requires that flag for PipeWire. This issue is about giving Electron apps the possibility to use PipeWire screen sharing by default, not necessarily making it fully work by default. So if Electron is built correctly, users or package maintainers can opt to run an Electron app with PipeWire, which has already been done with Slack Flatpak, since Slack builds with PipeWire support. Nevertheless, another issue could be opened to run with PipeWire support by default in Electron. Also, note --enable-features=WebRTCPipeWireCapturer is equivalent to setting #enable-webrtc-pipewire-capturer in chrome://flags to enabled.

Considering Slack already builds with PipeWire support, and in some testing in Slack no obvious regressions could be found, this feature should be reasonably suitable for production usage. X11 users should not be affected if Electron is built with PipeWire support (as supported by Slack already building with PipeWire in their official builds).

Chromium's implementation of PipeWire screen sharing is not yet perfect on Linux, as mentioned here and here. However, the alternative is no screen sharing whatsoever for Wayland Electron/Chromium users.

Tip: Easily test WebRTC screen sharing by visiting this page and clicking "Screen capture".

[danshick]

use_sysroot seems to have been enabled by default before, but was refactored out in this commit. Further down, this environment variable used to control whether or not sysroot was used by setting the build flag.

The flag should probably have been kept, even though sysroot is now the assumed default per this commit, to avoid issues like this one where other configurations depend on its value.

[vchernin]

Some news, it appears that this bug isn't really needed. Jitsi Meet Desktop which uses upstream Electron 12 can use PipeWire. This issue was meant to fix the lack of PipeWire by default in Electron. Since Jitsi uses official Electron and has PipeWire, there is nothing to fix here. Clearly PipeWire must actually be used by default (as has been suggested by Electron Members).

There are 3 apps that this issue was meant to try and improve: Microsoft Teams, Element Desktop and Jitsi Meet Desktop.

Microsoft Teams is proprietary and we don't know (to my knoweldge) what version of Electron they are on, which seems to cause their issue. It's entirely possible there are other reasons why it doesn't work, but since it's proprietary there is nothing really we can do other than upvote this issue. Now, it is possible this issue is somehow still relevant to Teams, but I just can't say for sure anymore. I don't have evidence that changing something in Electron would actually help Teams.

Element desktop has an Element and Jitsi specific bug which breaks screen sharing on every platform regardless of Flatpak, PipeWire, Wayland or Linux support.

Again, it appears that Jitsi Meet which uses upstream Electron 12 can screen share on PipeWire. "Solving" this bug likely won't help screen sharing in any Electron apps.

It seems likely that if Element fixes their bug, and if Teams would update/fix their Electron version, wayland screen sharing would basically work in all electron apps (while maybe passing --enable-features=WebRTCPipeWireCapturer).

I will leave this bug open for the moment in case anyone disagrees/has further thoughts that might help Microsoft Teams. Otherwise the lack of screen sharing on Wayland in Teams should be discussed in it's own issue (which should definitely be reopened).

Also if there are any other Electron apps which can't screen share on wayland feel free to link them.

[danshick]

Otherwise the lack of screen sharing on Wayland in Teams should be discussed in it's own issue (which should definitely be reopened).

I think this bug is resolved from electron's point of view. This issue shouldn't be reopened unless Microsoft builds Teams against the latest electron 12 and users still face issues with Wayland.

[sustmi]

Microsoft Teams is proprietary and we don't know (to my knoweldge) what version of Electron they are on, which seems to cause their issue.

@vchernin: Thank you for pushing this forward. Just for reference: I am using Teams v1.4.00.7556-1 on Fedora 34 installed from https://packages.microsoft.com/yumrepos/ms-teams/ repository. The screen sharing does not work with Wayland.

When I run it and show logs I can see this version information:

electron: 8.5.5, build: 7338844
...
-- event -- eventpdclevel: 1, name: desktop_previous_plugin_host_crashed, crashSession: ***, crashDesktopSession: ***, watchdogCrash: false, watchdogBlockingApi: null, watchdogLastPing: null, type: pluginHost, profileType: null, exitCode: 2, rendererName: pluginHost, crashType: killed, isOnBattery: unknown, remainingBatteryPercentage: unknown, electronBuild: 7338844, appRuntime: 236.064, ...

So I guess that Microsoft should step up their game a bit, because Electron 8.x.y is not supported any more.

[iMonZ]

Discord:

[2021-08-16 09:49:47.786] [21535] (audio_send_stream.cc:344): Failed to set up send codec state.
rtc_log_set_paused: false
rtc_log_set_paused error: monitor_option.is_none()
[2021-08-16 09:49:47.816] [21535] (audio_send_stream.cc:344): Failed to set up send codec state.
[2021-08-16 09:49:47.816] [21535] (audio_device_generic.cc:32): BuiltInAECIsAvailable: Not supported on this platform