Broken Screen Sharing on Linux Wayland

[vchernin]

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

[nkr0]

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]

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

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

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]

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]

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.

signalapp/webrtc@bca2e15

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]

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

[vchernin]

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]

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]

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]

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

[Sarath9087]

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

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

[Victor239]

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]

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]

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

[major-mayer]

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]

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]

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

[secresearch-rg]

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]

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]

Hello, is this bug fixed yet ?

[MatejKovacic]

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]

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

[qftlzxfz]

I also confirm that it now works in Wayland on Archlinux, with the above mentioned 3-step interface. I had to install the following packages, in case it may be useful for others:

xdg-desktop-portal
xdg-desktop-portal-gtk (not sure if this one is needed)
xdg-desktop-portal-gnome

[hdante]

Hello, I confirm that it's working in Wayland with Gnome shell on Arch Linux. 3 confirmation dialogs appear before it works.

[karlkashofer]

Still not working on Debian bookworm (12.1) with Signal 6.28
I get a window selection dialogue, but can not click any of the buttons in it.
The window-selection window is completely unresponsive and only goes away when i restart Signal.

[karlkashofer]

Still not working on Debian bookworm (12.1) with Signal 6.28 I get a window selection dialogue, but can not click any of the buttons in it. The window-selection window is completely unresponsive and only goes away when i restart Signal.

Found the problem ! Upon pressing the share button two windows are opened on top of each other. Only one is responsive, and it was the hidden one...
So, if the share window does not respond to clicks, Alt-Tab to the other sharing window, click there, and then the first one.

So sharing work also on Debian with Wayland, but is still a bit awkward. :)

[maymage]

@karlkashofer
What you describe may be electron/electron#32857

The good news is, that Electron-Wayland-Support is getting better in recent weeks.

[ayumi-signal]

We've added a workaround for Wayland which should help with the issue @karlkashofer described (2 share windows, active one uninteractable). If anyone continues to experience Wayland screen share issues, please share repro steps and info about your system. Thanks!

Edit: Updated link (thanks @qftlzxfz)

[qftlzxfz]

We've added a workaround for Wayland
The link does not work anymore.

Since a couple of weeks, I guess since the workaround was published, there are now 4 (!) windows to click through:

1: To select a screen
2: To select a window
3: With a preview of the selected screen and a preview of the selected window from the previous steps; one has to be chosen;
4: A window with two tabs "screen" and "window" and then one screen or window must be selected.

Then, it properly shares what has been selected, but it is not comfortable.

I am on Archlinux with the following packages installed:

signal-desktop 6.37.0-1
xdg-desktop-portal 1.18.0-2
xdg-desktop-portal-gnome 45.0-1
xdg-desktop-portal-gtk 1.15.1-1

Does anyone see or saw the same behaviour?

[ayumi-signal]

@qftlzxfz Thank you for the detailed report, and I updated the workaround link. Really sorry about the UX. I use Wayland every day and it's uncomfortable for me as well. It seems to be a bug in electron and we're waiting for a fix: electron/electron#32857

[major-mayer]

Is this really the correct upstream bug?
It seems to be about the file picker dialog open in background, not about too many portals/ dialogs when starting a screenshare on Wayland systems.
For me the file picker opens in foreground all the time, when I try to save a image for example, so this doesn't seem to be an issue.
But I definitely also see too many screenshare dialogs when starting the screenshare as @qftlzxfz describes.

[David-Else]

It is not working for me in Debian 12 and Flathub Signal Desktop 6.43.1 in Wayland (actually xwayland I believe). My friend and I both press start presenting and get an option to choose a monitor. We choose, and then that is it, nothing happens, no more options. We have looked for stray windows that are covering other ones and can't see any. Would really like to get this working!

[ayumi-signal]

@David-Else Sorry this isn't working for you. Can you please generate a Debug Log (View Menu -> Debug Log) and post the link here? The Flathub distribution isn't maintained by us so we don't support it officially, but it may be interesting to look at logs.

[David-Else]

@ayumi-signal Thanks for looking into this! Here is the log link: https://debuglogs.org/desktop/6.43.1/1f05c75cc978f60e7fe83f67524580367817201177fb3616294db04ea1661999.gz

I am assuming that there is no personal info leaked in this log...

[ayumi-signal]

@David-Else Thank you for that. It looks like there's an error when we do the electron call desktopCapturer.getSources():

ERROR 2024-01-06T15:35:42.495Z Error occurred in handler for 'getScreenCaptureSources': Failed to get sources.

Unfortunately this is hard to debug and it might be an upstream issue. Are you using any other electron based apps (e.g. Slack) with screen sharing and is it working in those apps?

As for logs, yes they are always cleaned of all personal info and safe to post.

[David-Else]

@ayumi-signal I am using OBS Studio in a flatpak to record screencasts, that seems to work fine, but it is not electron based.

[fluidvanadium]

im getting a similar bug

[113738:0116/191637.293103:ERROR:screen_capture_portal_interface.cc(48)] Failed to request session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/
desktop
[113738:0116/191637.293121:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 3
{"level":50,"time":"2024-01-16T19:16:37.293Z","msg":"Error occurred in handler for 'getScreenCaptureSources': Failed to get sources."}

my stack is
archlinux wayland sway pipewire wireplumber

[rmader]

Please ensure that you have the appropriate portal installed (xdg-desktop-portal-wlr for Sway / wlroots based DEs).

[David-Else]

@rmader Do you think my bug is from the lack of a poral? I have these installed, using Gnome in Debian 12 with flatpak:

dpkg -l '*xdg-desktop*' | grep '^ii'
ii  xdg-desktop-portal         1.16.0-2     amd64        desktop integration portal for Flatpak and Snap
ii  xdg-desktop-portal-gnome   43.1-2       amd64        GNOME portal backend for xdg-desktop-portal
ii  xdg-desktop-portal-gtk     1.14.1-1     amd64        GTK+/GNOME portal backend for xdg-desktop-portal

[rmader]

@David-Else No, that was just a reply to #5350 (comment), indicated by:

No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/

If pipewire capturing works for you with OBS, Firefox or Chromium, then the issue is likely in Signal.

[mehdisadeghi]

If pipewire capturing works for you with OBS, Firefox or Chromium, then the issue is likely in Signal.

Fwiw I have found Mozilla's RTC test page very helpful in making sure that screen casting works fine, before testing screen sharing with other applications.

[David-Else]

If pipewire capturing works for you with OBS, Firefox or Chromium, then the issue is likely in Signal.

Fwiw I have found Mozilla's RTC test page very helpful in making sure that screen casting works fine, before testing screen sharing with other applications.

Cheers. I tested it in Firefox, which I am running in Wayland mode, and it works perfectly! Signal is indeed broken.

@ayumi-signal Is there a timeline to update to the latest Electron? Maybe that will fix it?

[ayumi-signal]

@David-Else iIt's good to know Firefox is working for you! it would also be interesting to know if slack screenshare works for you.

As for a timeline to update Electron, we are always doing our best to stay up to date. Roughly we update major versions every 1 or 2 months and minor every 1-3 weeks.

I have to apologize about support regarding this issue -- we have limited engineering capacity, and for linux we need to prioritize issues affecting Ubuntu/Debian based systems using the official builds which unfortunately doesn't include the flatpak at the moment.

[fluidvanadium]

after multiple months of interrupted workflow, i solved this error for myself by double-clicking on the screenshare button!! my friend using x server only has to single click!