Signal-Desktop icon indicating copy to clipboard operation
Signal-Desktop copied to clipboard

Broken Screen Sharing on Linux Wayland

Open vchernin opened this issue 3 years ago • 94 comments

  • [x] I have searched open and closed issues for duplicates

Bug Description

Screen sharing on Linux X11 works, however Linux Wayland does not currently work. Virtually all Linux distros which default to Wayland (Fedora, Ubuntu 21.04, Debian 10, etc) also include PipeWire. PipeWire enables things like screen sharing on Wayland, and upstream Chromium includes support for it.

Please note native Wayland support is not necessary for screen sharing via PipeWire to work, Signal can be running in xwayland (not native wayland) and PipeWire screen sharing still works.

Steps to Reproduce

  1. Press the screen share button in a video call on Linux Wayland.

Actual Result:

On Signal on Linux Wayland (official .DEB packages, Ubuntu 21.04), the share button is there, but once you've selected a window and clicked share it won't actually work. That behaviour is expected given Signal does not try and enable PipeWire support out of the box.

Expected Result:

Screen sharing should work via the standard PipeWire/XDG-desktop-portal dialog.

If Signal is using standard WebRTC users should be able to pass --enable-features=WebRTCPipeWireCapturer at runtime or Signal could add that flag to main.js. Note you also need rtc_use_pipewire=true and use_sysroot=true enabled in Signal's Electron builds (upstream enables them by default). On second thought Chromium Flatpak is able to use PipeWire screen sharing without use_sysroot=true, so perhaps only rtc_use_pipewire=true is necessary.

Unfortunately, currently in Signal if you pass that flag the screen sharing button simply doesn't do anything which seems to be an issue on Signal's part (it could be due to incorrect build options as mentioned above). That button needs to be fixed for Linux Wayland screen sharing to work.

Platform Info

Signal Version: 5.4.1

Operating System: Ubuntu 21.04 (patched 2021-06-21)

vchernin avatar Jun 19 '21 17:06 vchernin

As an update, I can sort of share screen on wayland with signal v5.12. Sort of, because I could pick and share any individual window, but not the whole screen.

nkr0 avatar Aug 04 '21 18:08 nkr0

Sorry about this. I've reported it to our Calling team.

EvanHahn-Signal avatar Aug 05 '21 16:08 EvanHahn-Signal

As an update, I can sort of share screen on wayland with signal v5.12. Sort of, because I could pick and share any individual window, but not the whole screen.

For me by default Signal is able to share other windows running in xwayland. However all windows running in Wayland don't work, and whole screen doesn't work.

Correct PipeWire integration is still necessary here, especially as most apps migrate to Wayland-by-default.

As of 5.12.2 passing --enable-features=WebRTCPipeWireCapturer at runtime still results in a broken screen sharing button. As before, in Chromium/Electron that flag is a pre-requisite for PipeWire to be used (unless it's changed at build time).

vchernin avatar Aug 05 '21 23:08 vchernin

I've read in the Discord forums that if an application compiles the webrtc library on its own and doesn't use the one provides by electron /chrome, it also needs to be compiled again. This time with the new pipewire flags set to make it Wayland-compatible.

Could this also be the case for Signal?

major-mayer avatar Oct 28 '21 22:10 major-mayer

After hunting through Signal's various repos I finally found it. Signal is indeed explicitly disabling PipeWire (rtc_use_pipewire) in their forked WebRTC repo.

https://github.com/signalapp/webrtc/commit/bca2e1500ab87a7b425bbbe8b5d8378830f88a85

While Signal uses their own RingRTC library on top of normal WebRTC, the issue is still with their WebRTC fork since that is where PipeWire support is.

It looks like they disabled it due to failing builds. Their RingRTC test action is using ubuntu-latest which is 20.04, an LTS release that doesn't support PipeWire 0.3, which WebRTC depends on. However, that doesn’t seem to be what builds the actual RingRTC binaries they use, so I’m not sure which part of their system needs to be updated.

Possible solutions:

  • Use a interim Ubuntu release for the action until Ubuntu 22.04 is available as ubuntu-latest. A 21.04 or 21.10 container on top of 20.04 could be used, but that might require hunting down dependencies not in the container by default.
  • Use an older WebRTC release before PipeWire 0.2 was dropped which should still build on 20.04.
  • Wait until Ubuntu 22.04 is available OOTB for GitHub actions (20.04 only became available ~6 months after release it seems close to 10 months of waiting most likely).

WebRTC has improved their dma-buf support a lot in 96, so I'd prefer the first option.

vchernin avatar Dec 09 '21 21:12 vchernin

Any update on this? I am still not able to share my screen properly on Wayland with version 5.30

Altonss avatar Feb 10 '22 23:02 Altonss

Unfortunately no, someone needs to figure out where Signal‘s build configuration/deployment for RingRTC is (i.e. what runs copy_repo), if that’s even publicly accessible. I can only find linters and such.

vchernin avatar Feb 10 '22 23:02 vchernin

I still have this problem with Signal-Desktop 5.38.0-beta1 on Ubuntu with Wayland. I start a video call and also join with my cellphone. After sharing my whole screen on Desktop, on the cell I only get a black screen. Sharing a window works as expected. Here the debug logs of both devices:

Signal-Android: https://debuglogs.org/android/5.34.8/8976a58ccfdc6802af34644c71a0cedd099006c01f3bb98ec918f1492076b282 Signal-Desktop: https://debuglogs.org/desktop/5.38.0-beta.1/04fc0c98e9b0a37bde4aede8cf3d8a11f4d18186802454a48cf47f52a30d2c9a.gz

With Xorg both sharing the whole screen and sharing windows work without any issues.

sweah82 avatar Apr 02 '22 10:04 sweah82

Same thing here on Signal-Desktop 5.38.0. When starting with flag --enable-features=WebRTCPipeWireCapturer, the button to share screen is unclickable. When this flag is omitted, I am able to share screen, but only programs running in X compatibility.

klDen avatar Apr 08 '22 15:04 klDen

@indutny-signal can you take a look at this? Would be great if we were able to share screen on wayland.

thebrownfox avatar May 25 '22 09:05 thebrownfox

@scottnonnenberg-signal This has been a problem for a while. Screen sharing is completely broken. Can you look at this and possibly fix this in the next version?

Sarath9087 avatar Jun 05 '22 10:06 Sarath9087

Still a problem in v5.45.0 running Ubuntu 22.04 LTS + default Wayland

spipau avatar Jun 07 '22 21:06 spipau

Signal might be the first app I've seen that has a native Wayland version before they fully support being run on Wayland desktops. Even MS Teams supports PipeWire now with teams-for-linux --enable-features=WebRTCPipeWireCapturer.

Victor239 avatar Jun 24 '22 10:06 Victor239

teams-for-linux is the unofficial Electron app made by the community tho. https://github.com/IsmaelMartinez/teams-for-linux The official Microsoft app is way too outdated to support Pipewire based screen capture.

major-mayer avatar Jun 24 '22 10:06 major-mayer

the official teams uses chromium under the hood and also supports wayland screensharing nowadays.

stheid avatar Jun 27 '22 07:06 stheid

No that's simply not correct. Microsoft Teams uses Electron which is a combination of Chromium and Node.JS. But the version that they are shipping is too outdated to support screen capture via Pipewire. I just checked this myself and it's still the case, even when you try to force enabling this feature using something like this teams --enable-features=WebRTCPipeWireCapturer.

Users are complaining everywhere about this missing feature or update e.g.: https://answers.microsoft.com/en-us/msteams/forum/all/teams-screen-sharing-doesnt-work-on-linux/aa871d64-b600-442f-b751-d5e9b282ad37?page=2

major-mayer avatar Jun 28 '22 08:06 major-mayer

Now that Ubuntu 22.04 for GitHub actions is available in beta, Signal's forked WebRTC should build with the enabled rtc_use_pipewire flag. Hopefully we can have proper screen sharing support on Signal soon.

bacteriostat avatar Jul 06 '22 06:07 bacteriostat

thank you for your great work on signal, we really appreciate it. but please fix this :(

gothmog123 avatar Jul 25 '22 13:07 gothmog123

Now that Ubuntu 22.04 for GitHub actions is available in beta, Signal's forked WebRTC should build with the enabled rtc_use_pipewire flag. Hopefully we can have proper screen sharing support on Signal soon.

Ubuntu 22.04 for GitHub Actions is now generally available (Source). Any progress on the fix or plans to implement the new Actions runner yet for Signal?

secresearch-rg avatar Aug 16 '22 10:08 secresearch-rg

Tried virtual camera workaround with OBS and kernel module v4l2loopback (like in Zoom proposed here: https://support.zoom.us/hc/en-us/articles/6634039380877-Sharing-your-screen-on-Wayland) but it doesn't work as well :(

tomaszkubacki avatar Nov 05 '22 10:11 tomaszkubacki

Hello, is this bug fixed yet ?

hdante avatar Nov 06 '22 20:11 hdante

I just run to this problem with Signal 5.63.0 and Ubuntu 22.10 (using Pipewire). Any plans when this will be fixed? Because it is really affecting many users...

MatejKovacic avatar Nov 09 '22 18:11 MatejKovacic

Please could a contributor explain the problem? I understand https://github.com/actions/runner-images/issues/5998 can fix Wayland screen sharing, can someone please fix this?!

David-Else avatar Nov 23 '22 15:11 David-Else

Please could a contributor explain the problem? I understand actions/runner-images#5998 can fix Wayland screen sharing, can someone please fix this?!

Current explanation is on this comment: https://github.com/signalapp/Signal-Desktop/issues/5350#issuecomment-990251309

It's probably the correct explanation. Quoting it again:

After hunting through Signal's various repos I finally found it. Signal is indeed explicitly disabling PipeWire (rtc_use_pipewire) in their forked WebRTC repo.

hdante avatar Nov 23 '22 18:11 hdante

It's probably noteworthy that Pipewire support is still not enabled by default in upstream Chromium, see https://www.phoronix.com/news/Wayland-Chrome-Screen-Share-22. So maybe it's a deliberate decision to wait for things to stabilize first (even though I personally don't agree with it).

Side note: soon™ Pipewire will also be used for camera access in WebRTC, bringing a broad range of advantages such as portal/sandboxing support, concurrent camera use by multiple apps and support for more cameras through libcamera, see https://webrtc-review.googlesource.com/c/src/+/261620. That will also require the rtc_use_pipewire option.

rmader avatar Nov 24 '22 00:11 rmader

Has anyone tried building with rtc_use_pipewire = is_linux && use_sysroot against Ubuntu 22.04? Does it still fail? If not, is there a specific reason as to why leave pipewire disabled in the signal webrtc fork? Are we just waiting for upstream Chromium to enable it?

Neyl-123 avatar Dec 01 '22 21:12 Neyl-123

I switched to signal with all my clients and we haven't been able to screenshare for 2 years lol

gothmog123 avatar Dec 13 '22 17:12 gothmog123

I switched to signal with all my clients and we haven't been able to screenshare for 2 years lol

I've been using two different workarounds, both with pros and cons:

  1. Switch back to X11 from wayland. This is particularly easy when using GDM + Gnome Shell: set "WaylandEnable=false" in gdm configuration file.
  2. Keep wayland and use screensharing from Chromium with pipewire and a web-based screensharing app (Google Meet is an example).

hdante avatar Dec 13 '22 17:12 hdante

I switched to signal with all my clients and we haven't been able to screenshare for 2 years lol

I've been using two different workarounds, both with pros and cons:

1. Switch back to X11 from wayland. This is particularly easy when using GDM + Gnome Shell: set "WaylandEnable=false" in gdm configuration file.

2. Keep wayland and use screensharing from Chromium with pipewire and a web-based screensharing app (Google Meet is an example).

thanks. i'm actually trying to use the OBS virtual camera method but it's not working very well. i get a lot of stuttering in the call and audio/video de-synchronization. any tips on how that setup can be optimized? obs output settings maybe?

gothmog123 avatar Jan 04 '23 17:01 gothmog123

thanks. i'm actually trying to use the OBS virtual camera method but it's not working very well. i get a lot of stuttering in the call and audio/video de-synchronization. any tips on how that setup can be optimized? obs output settings maybe?

I have no idea

hdante avatar Jan 04 '23 20:01 hdante