Wayland screen sharing broken with GNOME 41 on Fedora 35

[intrlocutr]

Hi,

I recently updated to Fedora 35 with GNOME 41. This GNOME release restricts the screenshot API which Zoom has used for screen sharing on Wayland, so the screen sharing functionality no longer works (see here on Ask Fedora).

I require screen sharing for school, and I'm sure many others have a similar requirement/system configuration. With Wayland increasingly becoming a de facto standard on Linux, it is crucial that Zoom support Wayland screen sharing.

[ICD-12122]

it is a zoom issue, obs survived into gnome 41 just fine without any patches. since zoom just recently integrated into pipewire better, it seems like they installed some software lock on the gnome version or something even more stupid like static dependencies bundled up...

[intrlocutr]

Any integration Zoom has with pipewire was for desktop audio sharing. OBS uses the XDG portal, so it has no issues; Zoom uses a nonstandard, GNOME-specific, private API, which is now restricted to internal use by GNOME, therefore it doesn't work anymore. This is also why screen sharing does not work under Wayland compositors other than GNOME.

Personally, this problem does not affect me very much because I know how to switch to an X session. But there are, for better or worse, more people nowadays who are using Linux for the first time. They will have no idea what "Wayland" is, but they will no doubt be using it because it's the default on most mainstream distros now, again for better or worse. It will be a bad look for Zoom when these same less technically inclined users notice that OBS, firefox, chromium, etc. support screen sharing, and Zoom doesn't--not to mention the inconvenience of an essential feature missing.

[specialK]

Thank you! This is the first time someone has explained the underlying issue.

Zoom, if you're listening, Screen Sharing is a crucial feature for many Linux users.  We'd love it if you sorted out your Wayland support.

[es-kyra]

It's important to note that from the very beginning, Zoom incorrectly implemented their screensharing on modern gnu+linux distributions which use Wayland (as @zbrown mentions below). Zoom did not introduce Wayland support until March 1, 2020 version 3.5.361976.0301. This was broken upon release because they did not use the correct API (gdbus-org.freedesktop.portal.ScreenCast) which has been available since early 2018: https://github.com/flatpak/xdg-desktop-portal/releases/tag/0.10

This means that from the very beginning things were very broken: the performance was unusable (taking screenshots instead of video), issues with HiDPI displays, dysfunction for multi-monitor setups, and many other glitches. Now, the functionality is prevented entirely, and there were many warnings about this which were ignored. It is very inefficient for video but what's worse is it is also completely insecure because in order for it to be publicly enabled, applications have full access to record your entire screen without explicit permission.

The correct API was designed for video, and gives the user control over sharing specific windows/apps or the entire screen, so no app gets to spy on your screen without your permission. So when Zoom created their  implementation they used the wrong API, and for the almost two years since then Zoom still didn't update, ignored the users with issues, did not monitor for deprecating APIs, and did not test upcoming gnu+linux distributions like Fedora to see that the API they use was incorrect, long been deprecated, and imminently disabled. This left many users and developers to do the testing and investigation for them, but still took nine months to be recognized.

Finally, they are working on this now, so we will see how long the fix takes, and I hope they do some internal review to prevent situations like this going forward.

[ICD-12122]

What do you expect, arch, gentoo and fedora users have always been the screwed ones. And that is mostly fine b/c we chose to and are used to work around problems for the favor of being on the newest releases.

The reality is, a huge percentage of all users uses ubuntu. And zoom only dropped a solution for ubuntu, not for linux. So it is just about time for zoom to fix it now. But for them: They're still on time, because their main user base is still only minorly affected. Ubuntu only recently switched over by default to wayland, so now suddenly users might notice they can't do remote control anymore under wayland. That the screensharing sucks for their viewers they probably don't notice. However before the next iteration of ubuntu it is very unlikely that the current gnome release with the locked up API will hit on ubuntu. So in zoom's books they have just about time until that release.

A very common practice in the industry though, to only count the ubuntu users. And you can bet that the software development is vastly understaffed (at least linked in seems to confirm that), so linux is just a luxury problem here.

[zbrown]

---

@ICD-12122 wrote:

zoom only dropped a solution for ubuntu, not for linux

---

[citation needed] — where has a solution been provided for anyone? At best they have provided a hacky workaround and semi-acknowledged there is an issue (though later tried to pass the buck)

Additionally: Zoom explicitly supports GNOME on a range of systems, including Fedora, so it's rather tangential what may or may not be in any given Ubuntu LTS

We also aren't talking about an issue that's only recently emerged due to a new release, this issue has bee around for years — and has been reported by multiple commercial customers over that period

[ICD-12122]

> where has a solution been provided for anyone?

In x11 and then a barely working one for wayland. That was "ok" b/c most users used x11 thanks to ubuntu for a very long time.

> We also aren't talking about an issue that's only recently emerged due to a new release, this issue has bee around for years — and has been reported by multiple commercial customers over that period

Not for most of their customers. You fail to understand that their linux customers are a minority and the users that are not using ubuntu still running by default X11 and outdated packages an even bigger minority. If you really thought they love to support linux, it was probably more to keep the promise to run on every platform. And in their defence to be fair, they didn't had to transition in windows and mac or any of the phone OSs to make zooms functionality working again on a new platform (wayland).

This is just common sense, that the minority is not really important, since there are other issues, with customers that actually bring in the big money.

[es-kyra]

This issue will eventually affect 7 out of 13 supported operating systems (when used with gnome) listed on the system requirements page: https://support.zoom.us/hc/en-us/articles/201362023-Zoom-system-requirements-Windows-macOS-Linux#h_8...

This could have been avoided:

• During initial implementation
• In the many months leading to disabling the private API from public use which was communicated to developers through all official channels

Our company is much smaller and less well-resourced than Zoom, so we understand the difficulties of supporting all major operating systems. The frustrating bit is how many users and developers in Zoom's customer base had done (repeatedly) the research for free to solve this issue, but were ignored and ignored until it completely broke.

[zbrown]

Indeed, and I'm really not convinced by this ‘they only need to care about Ubuntu’ argument since:

1. Even on X11 using the new API is the correct/better solution
2. Ubuntu has supported Wayland as an opt-in for many years
3. RHEL and SLED actually have fairly notable shares of the enterprise market, exactly the market Zoom is targeting with their commercial plans
4. If Zoom only intends to support Ubuntu LTS, why explicitly list support for other systems? They've gone out of their way to declare support for other releases (like Fedora 21) that have been EOL for 5+ years
5. That still wouldn't make this okay, and I know that Ubuntu users have already faced issues for sometime and had reported them

[KimHarry]

Hmmm, I think it's not a big issue because if you update the latest zoom version then its works fine 

Regards: Grab The APK

[johnfparis]

This is big news, thanks! Which version of Zoom are you using, and which Fedora and Gnome?

[johnfparis]

It is not my experience that 5.10.4.2845-1 offers any improvement.

[despdx]

I just tested version (2845) on GNOME 41.5 & Wayland , myself, and as I reported, we do not yet have screesharing feature parity on Linux.  (Also, I'm using flatpak, not the official RPM.)  It is true, though; you can share the whole desktop on Wayland/GNOME 41.5.  I believe that was not the case when this thread was started.  So, some may consider it operational.  However, I think what this thread is tracking is the correct/proper solution, which is not yet released and is years overdue.   Most people watching this thread are waiting for that, from what I gather.  We also expect it soon, though.  I'm expecting to have application-specific share control when that is implemented, which is functionality that (I think) any application receives when using the GNOME/pipewire/wireplumber method for screen access.

[hoeze]

+1 on that. Zoom was the only reason why my university had to change back to X11 as default after updating to RHEL 8.
This probably won't be possible any more soon as all major distros run on Wayland now.

@Anonymous This issue is known since quite some time now.
Please solve it, there is no chance for others to fix your proprietary client for you.

https://community.zoom.com/t5/Meetings/Linux-screen-sharing-broken-in-new-client/td-p/3067
https://www.reddit.com/r/archlinux/comments/hr14sm/zoom_screenshare_on_wayland/

[despdx]

Hmm, just got caught by this.  I teach, so this is nonfunctional for me.  I guess I could switch to X11 desktop, as others are using as the workaround, but I'll have to install one.

[intrlocutr]

You don't need to install a new desktop to use X11, you can continue to use GNOME if you prefer. Log out, select your user, click on the circular button in the lower right, and select "GNOME on Xorg." Then just log in as normal and you should be on X. Once you select X it will remain the default so you won't have to select it every time.

GNOME should behave the same on X except for missing multitouch gestures.

[despdx]

Thank you, yes, this is very convenient and should be available for all installs of Fedora.  Nice; I had forgot about that.  This is a much better option than global.context.unsafe_mode=true, unless you want to turn it off/on every time and only when you need to screenshare.

[ICD-12122]

Well this is only an option if you don't want/need the new features that are wayland exclusive. Like multi touch gestures for laptop usage or multiple resolution scaling factors on different displays and more.

[Joho]

"GNOME on Xorg" is also (unfortunately) necessary if you would like to share a single window of an application - instead of the entire screen. Zoom implementation on Wayland does not have this option at all!

[despdx]

Oh, well, that's a good point and a serious problem, because, as Zoom users on Linux have found, any portion of the desktop that contains one of Zoom's own windows causes that portion of the screen to be shared as completely black, even if the window is *below* other windows. It's frustrating and confusing, and you can't tell it's happening, either.

[umermian]

Hi

Thanks For sharing This information to use this software:

I have one more suggestion you can visit this website:

The Gaming Quebec 

[MindlessDistanc]

I’d like to add a request for this as well.

I just used Zoom on Linux for the first time, running Fedora 35. Zoom is the only app on my computer which won’t share my screen under Wayland.

I tried using the browser version of Zoom instead (which does support screen sharing, although participants can’t see your cursor), but it squashes my video feed into a square, so it’s not useable.

I’ve got a bunch of video interviews for jobs over Zoom and I’d really love it if this worked out of the box. My mouse and touchpad don’t work properly under X11, so Wayland screen sharing support would be a big win. Please could Wayland support be added?

Thanks in advance

[leclairm]

I second all of what was previously said, just adding my voice to make numbers bigger. I need screen sharing for teaching and working with colleagues. Maybe there's a threshold in this company passed which they get a notification. But clearly the threshold is not time related, given the time since this issue was first raised.

[umermian]

Hi 

I second what was all recently said, simply adding my voice to make numbers greater. I want screen sharing for educating and working with associates. Perhaps there's a limit in this organization passed which they get a warning. However, obviously the limit isn't time related, since its getting late since this issue was first raised.

Regard:

new condos mississauga

[torsten1]

Me too.

[ICD-12122]

The thing is zoom is just ignoring the topic. Since pipewire became the official supported way for screen captures it is so dead easy I could write a screen recorder in a few minutes. And zoom could do it too, especially since they don't even need to use their own brain much, obs has it implemented and they would just need to take it as a reference (https://github.com/obsproject/obs-studio/blob/09b5290c7b3909a3086958986973740da44a42c2/plugins/linux...)

Their screenshot API they wrote for wayland right now was way more work and actually wasn't good at all. Sharing with a slideshow is absolutely not a standard you want to go for if you value a fluid experience for your viewers.

[tumbleweed]

The workaround of switching to X is not acceptable when you're working with HiDPI screens, at least in mixed resolution setups. It's just unusable on X, while wayland does it quite well. After all, wayland is where the mainstream Linux distros are heading/have migrated to, so support is a must-have.

For professional users, be it in education or private enterprises, it is not feasible to temporarily switch to a different window server every time you wanna show something to a colleague.

[Joho]

Not only screen sharing is broken on new Linux distros, but also sharing a single application window is not working under Wayland at all. @Zoom should step up and fix this if they would like to keep the market-share.  Alienating all of the new Linux users is not the best strategy.

And not only Fedora. Ubuntu already made several pushes for making Wayland the default. When it happens, Zoom will have no option, but to fix this. And if they would like not to angry loads of users in the meantime, they should start working on this pretty soon.

[rouhim]

Check this issue at gitlab how to workaround: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4665

Imagine the client would be open source and others could fix your crap.

[mnasledov]

Thanks, that works! Unfortunately GNOME then displays a lock icon with a warning next to it up in the status bar. I don't think I want to just leave that enabled all the time.

I hope that Zoom plans on fixing this soon. Until this workaround I've just been switching to Slack and I am lucky I haven't had to do any presentations lately

[despdx]

Actually, this workaround (global.context.unsafe_mode=true), is much less convenient that it first appears.  You have to reset this workaround setting *every time* you login to GNOME.  Plus, it is very difficult to send Alt+F2 to a VM.  So, I don't consider this a valid workaround if you use screen sharing regularly.  Maybe if you use it infrequently.

[Kristian]

Has anyone else noticed that this workaround seems to work only in regular zoom meetings, not when you are panelist in a webinar?

[johnfparis]

I'm surprised to hear it works at all for you anymore. When I try it, it only shares the background (desktop) and not any real windows at all.

For a workaround that works, use the OBS virtual camera, as explained here: https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/...

[xsrvmy]

A workaround without unsafe mode is to use OBS's virtual camera. Then you can use the share second camera option in advanced screen sharing. It sure is annoying though.

[YaBoiB]

Hello,
My name is Brandon. Thanks for joining the Zoom Community!

Zoom has a task to resolve this issue in a future release. I do not have the release version yet, but if you @all can remind me to check it from time to time, I will be happy to keep everyone here in the loop when we do have a release version. 

B!

[trq]

I thank you for taking the steps to implement Wayland Screensharing into Zoom.

[ICD-12122]

if this includes also remote control that would be superior (without that zoom is not a tool to work together anymore), however screensharing should be first prio.

[trq]

It would also be great if zoom supports pipewire audio sharing, because right now it requires pulseaudio for audio sharing.

[es-kyra]

This is a central feature for a supported platform, and it's important to note that the majority of your supported GNU/Linux distributions are GNOME-based, so while Fedora 35 may have been one of the first to hit it, the rest (Ubuntu, Debian, etc.) will soon follow as they pull in Gnome 41 or newer.

We have had a ticket open for six months about this, which just recently was escalated to tier 2 support…who simply told us to file a feature request. Very frustrating to have been told over and over "just try the new version of zoom" with no investigation into the cause (which we took the trouble to provide), nevermind checking whether the underlying issue was actually addressed in newer versions.

Then, to finally be told to just file a feature request, when the feature already exists, but it is completely broken and has been a ticking time bomb since the screencast API was deprecated in favor of the pipewire portal. GNU/Linux support has been a joke, many of our engineers avoid Zoom updates because they fix one thing and break three.

Maybe there is a reason people are looking at affordable, reliable, backed-by-open-source options like https://8x8.vc (powered by Jitsi). Plus, they didn't lie to their users about encryption.