Maintenance is being performed on Zoom's support site on November 4 that may cause support impact. For more information, please click here.
Everything you need to work together, all in one place.Explore Zoom One's Collaboration Tools
Connect virtually from anywhere with Zoom Meetings
Collaborate together with Zoom Chat
Call the world with Zoom Phone
Create and brainstorm with Zoom Whiteboard
Rich conversation analytics to improve sales
Send and receive messages and calendar invitations
Bring fluid interactions to hybrid teams with Zoom Huddles
Remove the hassle of traditional scheduling with Zoom Scheduler
Innovative video solutions for every meeting space.
Solutions to host impactful virtual and hybrid experiences.Find a Solution for Every Event
An omnichannel cloud solution optimized for video.
Zoom solutions elevate collaboration across vertical use cases.Discover Zoom Industry Solutions
Enabling exciting new ways to teach, learn, and connect globally
Transforming client engagement and employee experiences
Improving collaboration between agencies, ministries and constituents
Connecting care, collaboration, and medical innovation
Real-time communication, anywhere in the world
Bridging the in-store and online experiences
Expert support and services for all your design, strategy, implementation, event, and hardware needs.
An open platform that allows developers to build Zoom apps and integrations.
Zoom Partners bring Zoom's communications platform to market through alliance, sales, and service partnerships.
Discover new ways to use Zoom solutions to power your modern workforce.
Access expert-led tutorials on Zoom products and features.
Network with other Zoom users, and share your own product and industry insights.
Get documentation on deploying, managing, and using the Zoom platform.
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.
Solved! Go to Solution.
It's not a bug in xdg-desktop-portal-wlr, so I'm not going to create a pull request to add code that does nothing (if the client is behaving correctly...). There's already work on supporting to share only a region of the screen (https://github.com/emersion/xdg-desktop-portal-wlr/pull/156) which should coincidentally also fix Zoom.
Simply running Zoom with "env XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom" should be enough to make Zoom think it's on Gnome while still keeping dbus working.
Edit: This should not be marked as solution! If any, https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/... provides a workaround for the issue, which has to be fixed by Zoom!
this is good news! Do you know more about when it will happen?
Zoom's screen sharing broke on me without any warning in August/September after a zoom version upgrade, leading to problems during a conference presentation. Thankfully they were quickly solvable by having someone else screencast, but I've also seen that the performance is very bad. Having zoom fully functional by the start of the semester would be great!
Please put me on the notification list!
Any news on this? I was very close to buying a license for my company which runs 100% on Fedora Linux but it looks like this issue is still unresolved. The switch to X is not acceptable as it has security issues that we'd like to avoid.
Is there an ETA by now?
That is the same version as pre 5.11. You said version 5.11. will solve this issue. We are now in 5.12.6 and still problem persist on top of Fedora 35 will soon lose support so most of users are on Fedora 36 with Gnome 42. and problem persist.
I want to be able to answer all of your questions and I will as soon as possible. I am reaching out to the Zoom Team for more information. Please be patient with me about this case. If you all could create Zoom Support tickets about this, or if you have an open ticket can you share the ticket number with me in a PM and I can begin working these cases individually.
I will also reply publicly via this channel with more information as I receive it. Thank you @all for your concern about this sharing issue. I look forward to helping you all. Please do not share PII in this channel. Thank you.
After speaking to the Engineering team, we have found the root cause, Gnome adding more control on some of the Gnome interfaces with Wayland.
We are still working on a permanent solution but we do have a workaround at this time.
User can share desktop on Fedora 35.
Please test out this workaround and provide me with your thoughts.
found out is a big statement considering that his was documented in this very same thread... .
This disables security features and is disregarded. The same second you suggest that, your duty would be to make the users aware that they have to disable it as soon as possible again to not make themself vulnerable to certain threats. unsafe_mode does not set only the compositor in an unsafe mode.
And this not the root cause. The root cause is zooms half baked solution making screenshots instead of an actual screensharing. Start adopting pipewire correctly (like obs https://github.com/obsproject/obs-studio/blob/09b5290c7b3909a3086958986973740da44a42c2/plugins/linux...) and everything will be good. It got actually easier for your engineers, only thing you have to do is: Do it.
Thank you for saying this. It's absurd. And in a support ticket we had open, I had passed on the investigation long before this thread even existed. Would be nice to see real responsibility taken here instead of unfair blame shifting. Customers have been sounding alarms and Zoom has been covering their ears.
Even earlier, there were public tickets like this github tracker from January of 2019, where investigation was happening too: https://github.com/flathub/us.zoom.Zoom/issues/22#issuecomment-908619935
People took to twitter, and other ways to reach out. Nobody at Zoom listened while customers were sounding alarms.
You also have to do it every time you login to GNOME; it's not a persistent setting. Might be nice if you want a workflow where you enable this every time you want to screenshare and disable it when you finish screen sharring. You can even enable/disable this GNOME setting after you start you zoom meeting. So, you don't have to have unsafe mode enabled all the time. But, it's a real pain to have to turn this on/off if you use screensharing frequently.
I can assure you that your feedback is being reported to our team. Thank you for providing it. I continue to monitor this issue, and I continue to check on the case as often as possible.
Thank you, @all, for taking the time out of your day to provide valuable feedback to the Zoom Backend Engineers. They have expressed to me their appreciation as well personally.
A) there is a workaround. https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/...
B) Brandon indicates in this thread that this in under active development and implies that a solution has been successfully alpha tested. As he notes, no release date has been set but he is currently liaising with the developers.
That workaround is insanely obtuse and finicky. I, a long-time sysadmin and expert user, have problems setting it up.
"Active development" is talk. I've used that talk.
The company is ignoring people who are willing to help test in both depth and breadth.
The government market assumes Windows. The academic market is willing to use VMs for workarounds. It's just the rest of us. So it's not abandonware so much as abandon-us-ware.
This doesn't help at all when all I want to share is a single window (using a wayland desktop).
I can share my wayland desktops and windows with free big blue button using free firefox! With all your engineering power, it should be possible to match a free, open source product.
Im sorry but this is not an acceptable solution. This disables security features allowing any app to view your screen without explicit permission. Your comment should include a disclaimer or a warning about this if you are publishing this as a workaround.
The correct solution would be to implement pipewire and xdg-portal so that user can explicitly select the window or screen they want to share.
Thank you very much for connecting us, and no worries about the delay. Is there a way to send a PM or do you need to amend your original request? It may be worthwhile to ping the same users as they may have open tickets but given up trying to find a way to direct message on this site.
Thank you for your replies and please let me remind you of the Zoom Community Guidelines
Your replies have been heard and I will continue to provide this forum with any and all updated information concerning this ongoing case. If you have a current Support Ticket open please PM me the Zendesk ticket number(s) so that I can properly detail the agent that you are working with. Please do not post ticket numbers in the replies.
Thank you all,
well just read the replies here and you will. They developed only a screenshot api for wayland not an actual screenrecording b/c wayland didn't had any support for screen recording early on. This changed completely and the standard which all browsers also use by now is pipewire. So actually you can actually share your screen better with zoom in the browser, than installed on the desktop. It will be more fluent for your viewers since it is consuming an actual screenshare, not producing a slideshow.
And the reason gnome 41 does not work anymore is b/c it got more secure. The API has been closed to other processes, this means no one can peak at your screen without going through the components that can give them access to, with pipewire you get a window **from** pipewire which lets you select which output you want to give it access to (i.e. whole desktop, screen 1, screen 2 or just an application) and also decide to not give any permissions.
My name is Brandon. Thanks for your continued feedback and conversations on this channel. Please know that we take your replies very seriously, and we are providing this feedback to all teams within Zoom. We are still working on this solution, and I am working closely with the Zoom Engineering team to provide you with more information as it becomes available to me.
To be clear, GNOME has had a public, supported, Screencast API for many releases (which others have noted is used successfully used by OBS, Firefox, Chrome, et al)
What changed in GNOME 41 is that the underlying, private, APIs are no longer available to third-party apps — A change which known users (inc Zoom) were given advanced notice of.
The silly part is that that, as far as I know, the correct way has existed for as long as the incorrect — It's just Zoom decided not to use it, if they'd just used the proper API from the start there wouldn't have been any breakage and they'd even have gained KDE (and others) support by accident.
Then again it does seem to be the case that Zoom is trying to rapidly take screenshots rather than actually screencast, so is using another — older — private interface instead of the private ScreenCasting one instead of…
Thank you for your response. Please maintain Community Guidelines when posting on this thread. We appreciate that you have concerns, and we do take all responses seriously, but we must maintain professional decorum.
We really appreciate you bridging this issue with the engineering team at Zoom when all other official support channels failed to do so. Please maintain Community Guidelines when posting on this thread. We appreciate that customer expressions of dissatisfaction and poor experiences may not paint the company in a favorable light, and we do understand Zoom's position, but taking responsibility for mishandled issues (instead of throwing the book at calmly stated complaints) is part of maintaining professional decorum.
Now that you're taking a look at this, it would be great if you check also https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1121 where you can see that in Fedora 35 we don't only have the Wayland problem, but also the pipewire problem. In short, this distro is using pipewire-pulseaudio as a replacement of pulseaudio. Possibly it has some bug that you engineers can help fixing, as this is probably gonna be the default in all distros sooner or later (Fedora is just ahead of the curve). That issue is probably a good place where to raise your hand if you want to help on that. Anyway you'll probably have to use pipewire for proper screen sharing under wayland, so probably this is something you'll have to fix anyway.
Thanks for taking attention at this bug. We've been waiting for it for so long. ❤️
Hello @Yajo ,
Thank you for your insightful response. I have forwarded your response to the appropriate team. Please know that the Zoom Community hears your voice and we are listening.
I want to wish you and yours a wonderful Holiday Season from myself and the Zoom Community!
Kind and Respectful Regards,