Zoomtopia is here. Unlock the transformative power of generative AI, helping you connect, collaborate, and Work Happy with AI Companion.
Register nowEmpowering you to increase productivity, improve team effectiveness, and enhance skills.
Learn moreKeep your Zoom app up to date to access the latest features.
Download Center Download the Zoom appDownload hi-res images and animations to elevate your next Zoom meeting.
Browse Backgrounds Zoom Virtual BackgroundsEmpowering you to increase productivity, improve team effectiveness, and enhance skills.
Zoom AI Companion2021-11-04 09:57 AM - edited 2021-11-07 12:25 PM
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.
Solved! Go to Solution.
2022-07-14 08:51 AM - edited 2022-08-04 02:16 AM
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!
2022-01-13 02:11 AM
Dear Brandon,
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!
Best regards,
Kyrre
2022-05-18 12:49 AM
Hi, do you know if this issue is still being tracked/worked on? Ubuntu 22.04 is released and now zoom app (screen sharing feature) doesn't work by default in Ubuntu.
2022-06-09 04:03 AM
Hello YaBoiB,
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?
2022-06-09 06:08 AM
The ETA for 5.11.x is June 20th, so hopefully just a week and a half.
@YaBoiB wrote:Tentative release date is June 20th for version 5.11.0. Please note that this is a tentative release target date. We hope to make this date but it can be moved.
2022-06-09 07:15 AM
thank you, I missed this reply
2022-11-12 01:59 AM
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.
2022-03-15 07:55 AM
Thanks -- I explain in detail how to do that here: https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/...
2021-12-12 04:44 PM
Screen sharing in Wayland and Pipewire audio are both very important to me too
2021-12-13 11:59 AM
Hello @es-kyra @intrlocutr @Gene-Puppet @trq @ICD-12122 ,
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.
B!
2021-12-15 07:22 AM
Hello,
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.
Thanks,
B!
2021-12-15 08:08 AM
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.
2021-12-15 08:56 AM
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.
2021-12-15 01:46 PM
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.
2021-12-15 09:24 AM
It would be of great news if zoom supported screen sharing with audio on Wayland generally , like with Plasma Wayland or Sway WindowManager.
2022-01-11 09:34 AM
Hello @trq,
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.
Regards,
Brandon
2022-03-22 02:27 AM
There is currently no workaround for this and screen sharing has not been working for a really long time now, are you still supporting linux or is it abandonware at this time?
2022-03-22 04:50 AM
Two comments:
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.
2022-03-22 06:54 AM
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.
2022-01-03 02:23 PM
This works for me! Thanks!
2022-02-04 09:17 AM
I've tried this workaround, and while it appeared to work from my end, other Zoom participants reported seeing a black screen.
It's been over a month and a half -- any updates on when a real solution would be available?
2022-03-08 03:04 AM
This workaround no longer works. All that is now shared is the desktop (background) itself, not any of the (application) windows.
2022-03-08 03:59 AM
> enter global.context.unsafe_mode=true
TypeError: global.context is undefined
2022-03-18 06:51 AM
Hi Brandon,
Any update on getting this fixed?
2022-04-02 11:01 AM
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.
2022-04-09 01:35 PM
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.
2022-01-06 07:34 AM
2022-01-11 09:27 AM
I have reached out to the Technical Support Engineers on your ticket and provided them with some context on this issue. Apologies for the delay in getting back to you.
Regards,
Brandon
2022-01-12 07:48 AM
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.
2021-12-15 08:31 AM
please support this properly (as already mentioned) using pipewire, it will make a massive difference .
Also need this (fedora 35) to function properly, currently I'm locked with Xorg for work.
2021-12-15 12:36 PM
@all
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,
B!
2021-12-21 07:27 AM
I don't uderstand why zoom works more or less ok with wayland in gnome40 and not work on gnome 41...
2021-12-21 07:31 AM - edited 2021-12-21 07:36 AM
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.
2021-12-21 09:15 AM
Hello,
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.
Kind Regards,
B!
2021-12-23 02:19 AM
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…
2021-12-21 09:18 AM - edited 2021-12-21 09:19 AM
This issue breaks a major functionality of Zoom and is downright unacceptable for a production-ready application. Here's to hoping my engagement here also increases the chances of it realistically getting fixed. 🙄
2021-12-25 07:23 AM
Hello @befit_overlier,
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.
Kind Regards,
B!
2022-01-07 02:04 PM
Hi @YaBoiB,
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.
Warmly,
Kyra
2021-12-25 04:50 AM
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. ❤️
2021-12-25 07:37 AM
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,
B!🤗
2021-12-28 05:40 PM
We Need This Fixed ASAP! Please