Broken Screen Sharing on Linux Wayland

vchernin commented 3 years ago

[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

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)

nkr0 commented 3 years ago

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.

EvanHahn-Signal commented 3 years ago

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

vchernin commented 3 years ago

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).

major-mayer commented 2 years ago

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?

vchernin commented 2 years ago

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.

Altonss commented 2 years ago

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

vchernin commented 2 years ago

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.

sweah82 commented 2 years ago

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.

klDen commented 2 years ago

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.

thebrownfox commented 2 years ago

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

Sarath9087 commented 2 years ago

@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?

spipau commented 2 years ago

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

Victor239 commented 2 years ago

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.

major-mayer commented 2 years ago

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.

stheid commented 2 years ago

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

major-mayer commented 2 years ago

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

bacteriostat commented 2 years ago

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.

gothmog123 commented 2 years ago

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

secresearch-rg commented 2 years ago

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?

tomaszkubacki commented 1 year ago

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 :(

hdante commented 1 year ago

Hello, is this bug fixed yet ?

MatejKovacic commented 1 year ago

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...

David-Else commented 1 year ago

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?!

hdante commented 1 year ago

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.

rmader commented 1 year ago

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.

Neyl-123 commented 1 year ago

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?

gothmog123 commented 1 year ago

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

hdante commented 1 year ago

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:

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

gothmog123 commented 1 year ago

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?

hdante commented 1 year ago

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

MatejKovacic commented 1 year ago

Ubuntu 22.10 here (with Pipewire), with Signal Desktop 6.1.0. I am able to screen share Firefox, Chrome and one other app (Joplin). When I try to share my entire screen, the share is blank (black).

So it seems like a little improvement... :) but not really useful.

hdante commented 1 year ago

Ubuntu 22.10 here (with Pipewire), with Signal Desktop 6.1.0. I am able to screen share Firefox, Chrome and one other app

You can share the programs that are running under X with XWayland. That's why you can share Firefox and Chrome.

gothmog123 commented 1 year ago

This is getting really dumb. Any news on this?

hdante commented 1 year ago

I haven't tried screen sharing with signal recently, I've been using chromium for screen sharing on wayland, but I'm assuming no updates mean nothing has been fixed.

scottnonnenberg-signal commented 1 year ago

Signal's forked WebRTC should build with the enabled rtc_use_pipewire flag

We are still currently building to support Ubuntu 16, which means that we can't turn on that flag. If you have any ideas about how we can both use that flag and support downlevel linux, please let us know!

rmader commented 1 year ago

Signal's forked WebRTC should build with the enabled rtc_use_pipewire flag

We are still currently building to support Ubuntu 16, which means that we can't turn on that flag. If you have any ideas about how we can both use that flag and support downlevel linux, please let us know!

Ubuntu 16.04 - and in a month Ubuntu 18.04 as well - is end of life for non-paying customers. So if you don't have specific obligations to support Ubuntu ESM versions, you could go straight to Ubuntu 20.04 and have a sufficient Pipewire version.

Note that Google Chrome also requires Ubuntu 18.04 already and will likely shift to 20.04, soon, see https://support.google.com/chrome/a/answer/7100626?hl=en

If you have or want to support Ubuntu ESM versions for enterprise customers - then things get tricky of course.

vchernin commented 1 year ago

So if you don't have specific obligations to support Ubuntu ESM versions, you could go straight to Ubuntu 20.04 and have a sufficient Pipewire version.

Another idea to stick with building on Ubuntu 16.04, assuming WebRTC is built with RTC_USE_PIPEWIRE. Does Chromium/WebRTC actually need PipeWire's daemon and library present at runtime even for users who wouldn't use it like X11 users? So WebRTCPipeWireCapturer can be enabled at all times, I assume letting X11 users screen share regardless of PipeWire, while only Wayland users would obviously need to make sure PipeWire is present. But I don't know how Chromium tries to load/communicate with PipeWire and the screen sharing portal so this may not work.

Besides that I wonder if PipeWire could be built on Ubuntu 16.04 without much hassle.

hdante commented 1 year ago

Signal's forked WebRTC should build with the enabled rtc_use_pipewire flag

We are still currently building to support Ubuntu 16, which means that we can't turn on that flag. If you have any ideas about how we can both use that flag and support downlevel linux, please let us know!

Would it be possible to support both ? In my opinion, the upstream project shouldn't support Ubuntu 16 directly, instead it should support Ubuntu 22 and support for Ubuntu 16 should be applied downstream at distribution level (for example, using different compilation flags in the build recipe).

frzifus commented 1 year ago

does the latest signal-flatpak version run with the flatpak runtime that comes with ubuntu 16?

bacteriostat commented 1 year ago

Just tried a tool developed by David Edmundson and Aleix Pol called the XwaylandVideoBridge and the good news is screen sharing works using it on Plasma Wayland. It should work on any Wayland compositor but I don't think this would work on XOrg.

Here is the blog post for more details: https://blog.davidedmundson.co.uk/blog/xwaylandvideobridge/

Note: This is alpha quality software for now.

major-mayer commented 1 year ago

Very interesting, even though I would much prefer a native solution, especially since Signal is actually a Wayland-capable software, which is missing just a few bits for Pipewire streaming. But when this really gets integrated into some DEs, this could be quite huge.

gothmog123 commented 1 year ago

X11 is basically unmaintained at the moment. Signal can you please support the de facto "official" display protocol on Linux (wayland)?

gothmog123 commented 1 year ago

signal is pulling out all the stops, instead of fixing this, now the app is crashing every 2 seconds on wayland without clicking anything

gothmog123 commented 1 year ago

so the only way this is gonna be solved is when signal is forced by upstream to switch? nice. thanks signal. or maybe even then you're gonna patch out pipewire support purposely?

dimitris-personal commented 1 year ago

AFAIK with version 6.18 Ubuntu 16.04 and 18.04 are no longer officially supported. If so is it possible to make the flag switch to rely on pipewire on Wayland?

maymage commented 1 year ago

Upstream Electron

Upstream^2 Chromium

https://bugs.chromium.org/p/webrtc/issues/detail?id=15174

JustCryen commented 1 year ago

Not sure why but in my case, one PC has just the "black screen" when trying to capture but the other one segfaults the Signal app…

foonathan commented 1 year ago

I also have the segfault when enabling screen share. As a workaround, I've used the technique here to enable a virtual camera that contains my desktop: https://wiki.archlinux.org/title/V4l2loopback#Casting_Wayland_using_wf-recorder

qftlzxfz commented 1 year ago

I am also on Archlinux and also get a segfault as soon as I hit the share button. Very frustrating. As a side effect, the camera now works and keeps working beyond 10 seconds!

foonathan: your workaround gives me this error:

compositor doesn't support wlr-screencopy-unstable-v1

Did you run into that as well?

gothmog123 commented 1 year ago

The whole desktop app is a fucking mess. Its not like flipping on a switch for pipewire is gonna "destabilize" anything. For the sweet love of baby jesus signal could you just flip the switch and we'll deal with end of the world (which is already fucking here)

signalapp / Signal-Desktop