You're invited to Zoomtopia 2022! Our annual user conference will take place in the Americas on November 8-9 and in APAC, Japan, and EMEA on November 17.Learn more about our hybrid event experience
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
Innovative video solutions for every meeting space.
Bring meeting spaces online with Zoom Rooms
Conference Room Connector links existing rooms to Zoom
Innovative solutions for every space
Solutions to host impactful virtual and hybrid experiences.Find a Solution for Every Event
Host hybrid and virtual events with Zoom Events
Elevate your brand with single session events powered by Zoom Sessions
Broadcast at scale with Zoom Webinars
Host and attend classes, group events, and more OnZoom
An omnichannel cloud solution optimized for video.
Engage customers with Zoom Contact Center
Deliver intelligent support with conversational AI
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.
Flexible subscription plans for hardware
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.
Explore Zoom's technology ecosystem
Find a trusted Partner
Learn about Zoom's Partner Programs
Access marketing & sales resources
Login to the Partner Portal and click 'Learn'
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.
Keep your Zoom client up to date to access the latest features.Download Center
Download hi-res images and animations to elevate your next Zoom meeting.Browse Backgrounds
2021-11-04 09:57 AM - edited 2021-11-07 12:25 PM
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!
2021-12-28 10:54 PM
I just tried screen shared from vivaldi web browser(Chrome based) and it works! For now can be used as a ugly and annoying alternative. 😡
2021-12-30 10:11 AM
Just another Linux user who is asking mandatory feature., I would love to use zoom but now it is simply not possible to share my screen.
Go to xorg is not an acceptable solution, wayland is the default xserver in many distros, ubuntu 22.04 LTS will use it obviously.
2022-01-03 03:40 PM
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!
2022-01-20 09:24 AM
Do you have any updates on wayland and zoom screensharing compatibility ?
2022-01-06 08:42 AM
looking for support here too, paid account if that helps 😄
although i wish there were a workaround to temporarily disable whatever is blocking access to the api
2022-01-06 09:19 AM
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.
2022-01-09 08:35 AM
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 🙂
2022-03-23 05:07 AM
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!
2022-03-23 05:41 AM
Very well stated!
2022-03-23 09:43 AM
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.
2022-01-12 01:50 AM
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.
2022-01-13 07:49 AM
Please fix it Zoom!
2022-01-14 04:14 AM
Is there any update or timeline? This thread is open for a while without any real updates and it seams like the issue itself is know for a lot longer than this thread is open.
2022-01-19 01:08 PM
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.
2022-01-20 03:19 PM
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.
2022-01-19 01:20 PM - edited 2022-01-19 01:21 PM
Sorry, duplicate reply...
2022-01-21 01:30 PM - edited 2022-01-21 01:42 PM
Chiming in to report same issues with Slackware x86 and x64 Current and OpenSUSE 😞 - please add wayland support! Thanks
2022-01-22 04:34 AM
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.
2022-01-22 05:35 AM
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.
2022-01-22 03:27 PM
Good news, but confusing. Please clarify which specific version you mean. I'm assuming you mean the *next* release of Zoom, not the latest release. I tried the latest release, 5.9.1 (1380), on Fedora36/rawhide and it doesn't work.
2022-01-24 05:06 PM
The release notes page doesn't mention anything about fixing the issue in the next release https://support.zoom.us/hc/en-us/articles/205759689-Release-notes-for-Linux
2022-01-24 05:09 PM
I note that release has been delayed, an optimist could derive something from that I suppose
2022-01-25 07:21 AM - edited 2022-01-25 07:52 AM
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
2022-01-24 08:13 AM
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.
2022-01-24 11:29 AM - edited 2022-01-24 05:20 PM
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.
2022-01-25 09:57 AM
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.
2022-01-25 12:38 PM
I am confused as to why you are using this thread to bring up XOrg support in Fedora 36 when the issue at hand in Wayland support... can you please clarify?
2022-01-25 01:22 PM
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.
2022-01-25 01:36 PM
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
2022-01-28 04:15 AM - edited 2022-01-28 08:23 AM
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.
2022-01-28 07:55 AM
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.
2022-01-28 08:41 AM
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.
2022-01-28 11:20 AM
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:
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?
This is the main reason we are confused. Thank you for doing your best to communicate with the engineering team.
2022-01-28 12:42 PM
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.
2022-02-01 03:06 PM
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.
2022-02-01 06:34 PM
Hey @feaneron, the Zoom client is written in C++ using Qt 5. Do you have any examples that use that instead of GTK 4 and C?
2022-02-01 06:52 PM
I do not. The relevant bits of the mentioned code (connecting to a PipeWire remote from a file descriptor, creating a PipeWire stream from a node, etc) are mostly independent of the toolkit though. OBS Studio implements the same routines purely in OpenGL, for example.
2022-02-08 05:45 PM
Yes, we have already got this solution and are integrating it into zoom. but the specific release version has not been determined yet.
2022-02-08 06:22 PM
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.
2022-02-08 06:50 AM
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.