Introducing the new Zoom Community Champion Program where we recognize our most engaged community members for their contributions.Learn more and join
Everything you need to work together, all in one place.Explore Zoom One's Collaboration Tools
Innovative video solutions for every meeting space.
Solutions to host impactful virtual and hybrid experiences.
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.
Explore over 1,500 apps in Zoom App Marketplace
Documentation for building on Zoom's platform using APIs, Webhooks, and SDKs
Resources that help developers evaluate & build with our solutions
Post your questions and get help from our developer community
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!
My name is Brandon. Thanks for joining the Zoom Community! Thank you all for your continued patience while we work on a solution to this issue. As I have stated previously on this thread, I will be sure to reach out with any updated information as soon as it is available to me. @All, please be patient as we work on a solution with the Zoom Engineers. I hope that every one of you had a joyous New Year!
there is a workaround, also not recommended, see the other comments above.
but the better workaround then making the api unsafe again:
join from the browser and share over that. by that you get a proper screensharing because all major browser implemented over 1 year ago what zoom still has to do.
I'm writing to ask if there are any updates to future releases with this bug fix. I know of personally 3 organizations who are waiting for a release so that they can continue using their machines for zoom conferencing (school lectures, business meetings, church services, etc) so even a rough timeline of when the critical bug is fixed would be much appreciated. Many thanks 🙂
I have been watching this space actively for the last 3 months. It seems to me that up until now there has been no clear indication of even a timeline of when this bug will be fixed.
While this situation is not as bad Virtual Backgrounds (I was also part of the community who posted a feature request on the developer forum), someone has taken the time to create Write up of the problem (link attached)
This is in hopes that zoom will not just hopefully making a fix in this issue, but also to look into Zoom’s continued discrimination against Linux users, (at the very least putting us as second class citizens). I do understand that there are business priorities, and I don’t expect you guys to look into every bug that needs fixing. I only have issues with the underlying message you guys are putting out.
To my understanding, help has been offered even by one of the gnome developers, but until today this fix has been under ‘Active Development’ with no clear timeline on when this crucial bug will be fixed.
If Zoom as an organisation has decided that supporting Linux distros as a first class citizen is not in your business priorities, I ask that this is clearly communicated, and that you guys clearly communicate that this is not a priority for now.
If you guys actually do see the value in supporting linux clients, then I ask that you guys take clear actionable steps to assure us that we can continue using Zoom in our organisations.
I do not wish to stop using zoom as I believe it’s a great platform to connect with my colleagues, friends and family. If there’s anything we can do as a community please communicate that because I believe we are more than willing to work together to make this product work!
someone has taken the time to create Write up of the problem (link attached)
To quote that writeup…
Will Zoom look into why all of their support agents ignored clear descriptions of not only how but also why Zoom itself was broken? Will they start actively testing all supported desktop linux OSes—and ideally their beta releases to detect upcoming issues sooner? Will they form closer ties with the Free Software/Open Source community and benefit from all the effort that volunteers put into diagnostics and debugging? Will they actively monitor official channels for API deprecation? Will they hire any developers that use a modern GNU+Linux OS as their daily driver? At so many turns could this outcome have been avoided.
I am also affected by this, and have been from the beginning. I am running Sway which is a wl-roots based compositor for Wayland which has an implementation of the standard xdg-desktop-portal which zoom should be using in order to properly support every Linux use case in a single shot. It really bugs me to have to logout and log in to an (from my perspective) inferior desktop in order to participate in a zoom meeting. As I work in the academic space where Zoom is ubiquitous, at least in Sweden, while at the same time having a large Linux user base this is problematic not only for me, but for many of my colleagues a cross many universities.
I've filed tickets with Zoom about this issue since I first discovered the problem at the beginning of last year with Fedora Linux 34 with KDE Plasma using Wayland. In those tickets, I also provided the technical approach to solving the problem. When it also hit Fedora Linux 35 with GNOME using Wayland, I detailed it once again and asked for some more urgency to resolve the issue.
What was particularly galling is that the tickets were closed implying that my problem was solved, but it's quite obviously not. It sounds like it's being worked on now, though, so I'd really like to know when that will ship.
We will create a support ticket for you, and I will work with you on this issue. To all other users on this thread, if you already have a support ticket created and it is being worked on by a member of the Zoom Support Technical Support Engineers, please reference this thread to the agent to assist you on a one-on-one basis. Please know that this issue is still considered a high-priority case, and we are diligently working with the Zoom Engineering Team to find a solution.
Update on this issue. The latest Zoom Version is now working on Fedora 36. I do not have this version installed. I am relying on internal information for this resolution. Please install the latest Zoom Version for Fedora 36 and provide your feedback to this thread.
Once again, thank you to all who have reported and provided valuable feedback. We at Zoom genuinely appreciate the feedback and assistance. Please continue to supply feedback to this thread.
Fedora 36 is 3 months in the future and doesn't yet exist as a specific thing you can install
Assuming by latest you mean 22.214.171.1240 (which is what the website currently gives me) screencasting is still unavailable and looking at the bus Zoom is still making forbidden calls to private screenshot APIs (which of course fail) — So either your internal sources have something newer than we do, or they seem to be mistaken.
The latest Zoom Version is now working on Fedora 36. […] Please install the latest Zoom Version for Fedora 36 and provide your feedback to this thread.
I have just installed Version: 5.9.3 (1911). No change. Still PulseAudio warning. Still no displays or windows are detected.
EDIT: After upgrading the rest of the packages on my system, I did see multiple displays which could be shared. I assume this means Zoom targets some dependency that isn't met on a base F35 install, only F36. That means also that all earlier versions and distributions are left probably out of this fix. 🤦
If it's useful, here's the package comparison between when it didn't work (before/left) and when it did (after/right):
$ rpm-ostree db diff 4bb8301ce5639227589617b788943b1f95f93889407eec1ee63a762cb0a94c01 0a57bed3e1968eb3105ff8098569beb0449afeda7cd65285bd6308e1ec817b07 ostree diff commit from: 4bb8301ce5639227589617b788943b1f95f93889407eec1ee63a762cb0a94c01 ostree diff commit to: 0a57bed3e1968eb3105ff8098569beb0449afeda7cd65285bd6308e1ec817b07 Upgraded: abattis-cantarell-fonts 0.301-3.fc35 -> 0.301-5.fc35 audit 3.0.6-1.fc35 -> 3.0.7-1.fc35 audit-libs 3.0.6-1.fc35 -> 3.0.7-1.fc35 chrony 4.1-3.fc35 -> 4.2-1.fc35 crun 1.4-1.fc35 -> 1.4.1-1.fc35 cryptsetup 2.4.2-1.fc35 -> 2.4.3-1.fc35 cryptsetup-libs 2.4.2-1.fc35 -> 2.4.3-1.fc35 cups 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35 cups-client 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35 cups-filesystem 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35 cups-filters 1.28.10-2.fc35 -> 1.28.11-1.fc35 cups-filters-libs 1.28.10-2.fc35 -> 1.28.11-1.fc35 cups-ipptool 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35 cups-libs 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35 distribution-gpg-keys 1.60-1.fc35 -> 1.61-1.fc35 dnsmasq 2.86-3.fc35 -> 2.86-4.fc35 ethtool 2:5.15-1.fc35 -> 2:5.16-1.fc35 evolution-data-server 3.42.2-1.fc35 -> 3.42.3-1.fc35 evolution-data-server-langpacks 3.42.2-1.fc35 -> 3.42.3-1.fc35 expat 2.4.1-2.fc35 -> 2.4.3-1.fc35 flatpak 1.12.2-1.fc35 -> 1.12.3-1.fc35 flatpak-libs 1.12.2-1.fc35 -> 1.12.3-1.fc35 flatpak-selinux 1.12.2-1.fc35 -> 1.12.3-1.fc35 flatpak-session-helper 1.12.2-1.fc35 -> 1.12.3-1.fc35 freetype 2.11.0-1.fc35 -> 2.11.0-2.fc35 gstreamer1-plugins-bad-free 1.19.3-1.fc35 -> 1.19.3-4.fc35 gupnp 1.4.1-1.fc35 -> 1.4.3-1.fc35 gutenprint 5.3.4-5.fc35 -> 5.3.4-6.fc35 gutenprint-cups 5.3.4-5.fc35 -> 5.3.4-6.fc35 gutenprint-libs 5.3.4-5.fc35 -> 5.3.4-6.fc35 harfbuzz 2.8.2-2.fc35 -> 2.9.1-1.fc35 harfbuzz-icu 2.8.2-2.fc35 -> 2.9.1-1.fc35 hplip 3.21.2-15.fc35 -> 3.21.12-1.fc35 hplip-common 3.21.2-15.fc35 -> 3.21.12-1.fc35 hplip-libs 3.21.2-15.fc35 -> 3.21.12-1.fc35 ibus-m17n 1.4.8-1.fc35 -> 1.4.9-1.fc35 ibus-typing-booster 2.15.11-1.fc35 -> 2.15.15-1.fc35 initscripts-service 10.11-1.fc35 -> 10.13-1.fc35 kernel 5.15.14-200.fc35 -> 5.15.16-200.fc35 kernel-core 5.15.14-200.fc35 -> 5.15.16-200.fc35 kernel-devel 5.15.14-200.fc35 -> 5.15.16-200.fc35 kernel-modules 5.15.14-200.fc35 -> 5.15.16-200.fc35 kernel-modules-extra 5.15.14-200.fc35 -> 5.15.16-200.fc35 libibverbs 38.0-1.fc35 -> 38.1-2.fc35 libical 3.0.12-1.fc35 -> 3.0.13-1.fc35 libical-glib 3.0.12-1.fc35 -> 3.0.13-1.fc35 libmetalink 0.1.3-15.fc35 -> 0.1.3-24.fc35 libsane-hpaio 3.21.2-15.fc35 -> 3.21.12-1.fc35 libwacom 1.12-1.fc35 -> 1.12.1-1.fc35 libwacom-data 1.12-1.fc35 -> 1.12.1-1.fc35 libwebp 1.2.1-3.fc35 -> 1.2.2-1.fc35 libxcrypt 4.4.27-1.fc35 -> 4.4.27-2.fc35 libxcrypt-compat 4.4.27-1.fc35 -> 4.4.27-2.fc35 libxcrypt-devel 4.4.27-1.fc35 -> 4.4.27-2.fc35 libzstd 1.5.1-6.fc35 -> 1.5.2-1.fc35 mesa-dri-drivers 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-filesystem 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-libEGL 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-libGL 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-libgbm 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-libglapi 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-libxatracker 21.3.3-1.fc35 -> 21.3.4-3.fc35 mesa-vulkan-drivers 21.3.3-1.fc35 -> 21.3.4-3.fc35 mtr 2:0.94-4.fc35 -> 2:0.95-1.fc35 pam 1.5.2-5.fc35 -> 1.5.2-7.fc35 pcre2 10.37-4.fc35 -> 10.39-1.fc35 pcre2-syntax 10.37-4.fc35 -> 10.39-1.fc35 pcre2-utf16 10.37-4.fc35 -> 10.39-1.fc35 pcre2-utf32 10.37-4.fc35 -> 10.39-1.fc35 pipewire 0.3.43-1.fc35 -> 0.3.43-3.fc35 pipewire-alsa 0.3.43-1.fc35 -> 0.3.43-3.fc35 pipewire-gstreamer 0.3.43-1.fc35 -> 0.3.43-3.fc35 pipewire-jack-audio-connection-kit 0.3.43-1.fc35 -> 0.3.43-3.fc35 pipewire-libs 0.3.43-1.fc35 -> 0.3.43-3.fc35 pipewire-pulseaudio 0.3.43-1.fc35 -> 0.3.43-3.fc35 pipewire-utils 0.3.43-1.fc35 -> 0.3.43-3.fc35 python-unversioned-command 3.10.1-2.fc35 -> 3.10.2-1.fc35 python3 3.10.1-2.fc35 -> 3.10.2-1.fc35 python3-audit 3.0.6-1.fc35 -> 3.0.7-1.fc35 python3-libs 3.10.1-2.fc35 -> 3.10.2-1.fc35 python3-rpm 4.17.0-1.fc35 -> 4.17.0-3.fc35 qgnomeplatform 0.8.3-2.fc35 -> 0.8.4-1.fc35 qt5-qtwayland 5.15.2-15.fc35 -> 5.15.2-17.fc35 rpm 4.17.0-1.fc35 -> 4.17.0-3.fc35 rpm-build-libs 4.17.0-1.fc35 -> 4.17.0-3.fc35 rpm-libs 4.17.0-1.fc35 -> 4.17.0-3.fc35 rpm-plugin-selinux 4.17.0-1.fc35 -> 4.17.0-3.fc35 rpm-sign-libs 4.17.0-1.fc35 -> 4.17.0-3.fc35 sane-backends 1.0.32-5.fc35 -> 1.1.1-1.fc35 sane-backends-drivers-cameras 1.0.32-5.fc35 -> 1.1.1-1.fc35 sane-backends-drivers-scanners 1.0.32-5.fc35 -> 1.1.1-1.fc35 sane-backends-libs 1.0.32-5.fc35 -> 1.1.1-1.fc35 selinux-policy 35.8-1.fc35 -> 35.11-1.fc35 selinux-policy-targeted 35.8-1.fc35 -> 35.11-1.fc35 shadow-utils 2:4.9-8.fc35 -> 2:4.9-9.fc35 shadow-utils-subid 2:4.9-8.fc35 -> 2:4.9-9.fc35 texlive-lib 9:20210325-40.fc35 -> 9:20210325-44.fc35 thermald 2.4.6-3.fc35 -> 2.4.8-1.fc35 virtualbox-guest-additions 6.1.30-1.fc35 -> 6.1.32-1.fc35 webkit2gtk3 2.34.1-2.fc35 -> 2.34.4-2.fc35 webkit2gtk3-jsc 2.34.1-2.fc35 -> 2.34.4-2.fc35 wireplumber 0.4.5-3.fc35 -> 0.4.7-2.fc35 wireplumber-libs 0.4.5-3.fc35 -> 0.4.7-2.fc35 Removed: chkconfig-1.19-1.fc35.x86_64 initscripts-10.11-1.fc35.x86_64 Added: avahi-tools-0.8-14.fc35.x86_64 cups-filters-braille-1.28.11-1.fc35.x86_64
Just stopping by to add some representation to this issue. A fix would be lovely here. Haven't yet tried the workaround mentioned above, but my current workaround has been to talk people out of using zoom, and do Slack and Teams meetings instead 😉 though I'd like to get back to Zoom when it's an option.
@YaBoiB thanks for keeping an eye on this.
I share all of the comments above about Zoom's handling of support for various flavors of Linux. IMO, Zoom's Linux support has always been pretty mediocre.
As a result, I switched to Google Meet wherever I could. Although Google Meet had performance issues early on, in the last six months or so it's become at least as good as Zoom, and screen sharing is more versatile (Chrome tab, any window, or entire screen). Not requiring a software installation is terrific. And, if you use Google calendar, the integration between them is extremely convenient. The biggest problems I've faced are 1) resistance to change, 2) screen sharing permissions often catch people unaware.
Microsoft Teams is also really good.
I'm not trying to spite Zoom. But I am saying that Zoom's unwillingness or inability to adapt to web video and to fix its broken sharing on Linux is quickly causing it to become a legacy product for me.
Let me clarify that Fedora 36 has not yet been officially released to date. We did testing, and this is working on Xorg. This issue is on our Roadmap for a future release and will be sorted out soon. My apologies for the confusion to anyone in this thread. That was not my intention. I intend to assist in finding a solution for all users in this thread and any users experiencing this issue. Again, I truly appreciate everyone who has replied to this thread and those who have helped in providing logs and experiences for this case. It is still a top priority for our team, and we thank you all for your patience while we sort this out.
I don't think the statement applies to F36, specifically. It means that, if you use Xorg instead of Wayland, then Zoom screen sharing works. This is legacy behavior that "always" worked. So, as a one of the two workarounds suggested by various posts in this thread for the current issue, you can switch to Xorg-based desktop (or GNOME on Xorg) to get screen sharing to work. I know, this thread is pretty long.
Yeah I'm a bit unclear why we should be excited about Zoom supporting legacy graphics on an unreleased future system.
Especially when it would somewhat imply Zoom aren't making use of the appropriate XDG APIs, as they are agnostic and so it would work on Wayland not just X11 — even if, for some reason, need a bleeding-edge system.
Hopefully this is just a miscommunication and will all be cleared up shortly
The latest Zoom Version is now working on Fedora 36. […] Please install the latest Zoom Version for Fedora 36 and provide your feedback to this thread.
These two messages are completely opposite.
We did testing, and this is working on Xorg. This issue is on our Roadmap for a future release and will be sorted out soon.
The team should stop testing on a configuration that is not the default for the operating system in question. Like @Gene-Puppet and @zbrown said, it was already working on Xorg. That's like saying "This is fixed, we tested on MacOS". Why would you say this?
I have attached a screenshot of how the newly released Zoom operates. When I plugged in my microphone and Zoom detected it, the messages continued to flood my screen, preventing me from interacting with Zoom so I could not even exit gracefully.
Notice how it was said that the latest Zoom release was "working" on Fedora 36 (which isn't even out yet, but whatever). There is apparently a discrepancy between how Zoom defines "working" and how users define it. According to Zoom, the release is "working" if the program launches, but it is obviously not working from the users' perspective because we are still missing a key feature.
Please understand that the information I am providing is coming from the Engineers directly, so it is not uncommon for them to possibly have a beta version of Fedora 36. I believe that you all would agree on this point. To note: I am not the Engineer testing this. I am simply acting as a liaison to attempt to solve this issue for the good of the customers of Zoom. That is my sole goal. I truly appreciate the positive feedback on this issue and the help that many have volunteered. It has not gone unnoticed. As soon as I have more information from the team, I will post it here.
it is not uncommon for them to possibly have a beta version of Fedora 36.
I agree, I did not say anything negative about testing an early version of Fedora—I think that's a good thing and was recommending this type of testing earlier in discussion. If you read my message, I only point out Xorg:
This is the main reason we are confused. Thank you for doing your best to communicate with the engineering team.
not uncommon for them to possibly have a beta version of Fedora 36. I believe that you all would agree on this point
Hate to be petty, but no not really 🙂
Fedora isn't Zoom's product, furthermore Fedora 36 doesn't hit beta for another month and doesn't even exist as a branch yet. Until the 8th of February your engineers simply can't be using Fedora 36 beta-or-otherwise. Of course they are probably referring to Fedora Rawhide, but that is somewhat distinct from "Fedora 36" and I'm not sure why Fedora 35 is insufficient in the first place.
Unfortunately your last few responses have been more confusing than "helpful", but thank you for your continued efforts. Hopefully "the team" have something more useful to say soon.
My name is Georges Stavracas, and I'm one of the maintainers of GNOME Shell, xdg-desktop-portal, among others. It seems to me that the developers at Zoom are aware of this issue, and a solution seems to be on its way. This is exciting news.
However, I do notice that you reported that it "[...] is now working on Fedora 36". This concerns me. I do not know what checks are performed by the Zoom client, but based on this statement, I can make a few educated guesses, and these checks are probably wrong.
I'd like to offer help to your development team on this front. You can contact me, publicly or privately, under NDAs or not, under contracts or not, using the email that this account is registered with. I would absolutely love to help making Zoom work on Wayland, and potentially also Flatpak, like I did with other software like OBS Studio.
I have code under Public Domain that exemplifies the usage of the Screensharing portal. This code can be copied into proprietary applications, your developers should feel free to use it.
Please let me know what you think.
Wonderful. As mentioned, feel free to reach out if you have any questions or problems interacting with the ScreenCast portal - some of the APIs there can be slightly tricky to get right; see referenced code above. If you find bugs in the portal, please report them at github.com/flatpak/xdg-desktop-portal.
We are aware of the issue and aware of the solution, so although we appreciate your offer for help, our Engineers have it under control at this time. They plan on implementing the solution in a future version of Zoom. I do not have that version number to date. I will update everyone here when I have that information. Thank you for being so patient while we continue to work on this.