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!
2022-06-21 01:55 PM
The Linux deployment has been slightly delayed for version 5.11.0, but it should be completed by tomorrow end of the day US time. Sorry for the inconvenience. I know that many of you have been waiting for a long time for this version to be released. I do not know the reason for the delay.
2022-06-21 04:01 PM - edited 2022-06-21 04:07 PM
could you fix the fact that it still says you need to use GNOME to screenshare in the next release? (though with a hack it "works" on any other desktop environment/window manager, but other users won't be able to see your screen)
It also doesn't make sense to place a random artificial restriction on screensharing when it is meant to work across all desktop environments
2022-06-23 02:04 AM
thank a lot mate for all the effort you put to make this happen. May Linux and the power of Free Software be with you.
2022-06-23 09:03 AM
We are still not done, they still have to remove that random restriction for gnome only
2022-06-29 11:37 AM
Tested on Fedora 36 Gnome 42 x86_64 with zoom version 5.11.1. Able to screen share a specific google chrome window. But the window does not show the "green border". Is this a known issue ?
2022-06-29 01:17 PM
I have not seen this reported to date. I can look into it and see if we have any other reports of the green border not showing up on an application share.
2022-06-29 01:27 PM
I've also seen this on full-screen shares missing the green border.
Since upgrading to 5.11.x, while screensharing in gnome w/wayland again is working:
I've also had a few cases of zoom freezing up while sharing, often when switching from full screen share to windowed share. Folks can still see and hear me, but the zoom UI is frozen, no changes, no response to input.
2022-06-29 02:48 PM
2022-06-29 04:07 PM - edited 2022-07-05 02:00 PM
Unfortunately that is impossible to fix, but you CAN fix the fact that screensharing doesn't work on all desktop environments (so pls fix it)
the reason I say that is because wayland does not really support layering (zwlr_layer_shell is an option, but not a great one, it only works on kde and wlroots at the moment) , so you can't layer that yellow box on top of the window, nor can you add it as a custom decoration or smth.
2022-07-05 09:48 AM
2022-07-05 01:17 PM
@ck1234, No updates that I am aware of but we were off since July 1st, so I will have to check on it and get back to you. Do you have a support ticket number that I can reference?
2022-07-05 01:42 PM
2022-07-05 02:25 PM
2022-06-22 04:58 AM
So, I _think_ it worked for a second or two (didn't get to check on another client) before it segfault'd
It's just done it three times in a row
2022-06-22 05:02 AM
Update: Also consistently happens when sharing the whole screen
This on an entirely up-to-date freshly rebooted fc36 system.
Feels like delaying til the 3rd wouldn't have been a terrible idea…
2022-06-23 03:53 AM
Yeah I have the same issue on one of the laptops on Fedora (posted already here a few minutes ago), it works on the others so either a gpu driver issue or a library I don't have installed on that one.
2022-06-22 05:27 AM
Well, you got me excited there for a second. It at first seems to work on Sway but then other participants don't see your screen at all as others have reported with KDE.
Zoom even uses the dmabuf variant of ScreenCast, which would be great if it only worked. Forcing it to SHM, xdg-desktop-portal-wlr complains about Pipewire being out of buffers the whole time, not sure what's going on there (and Zoom eventually crashing).
Would be interesting to know whether xdg-desktop-portal-gtk does anything different regarding screensharing than the other implementations.
All in all this is a very disappointing experience.
2022-06-23 10:23 AM
So you can at least try and share your screen on sway. When I trick zoom to let me try to share my screen like this
XDG_CURRENT_DESKTOP=ubuntu:GNOME XDG_SESSION_DESKTOP=ubuntu zoom
It lets me try to share my screen with the gnome-looking screen-share application window as an option. But selecting it just backs me out of the screen share window like it tried to do something but nothing happens. I even have xdg-desktop-portal-wlr but still no luck.
I mean fixing it so i can at least share a blank screen won't do me much good but I'm curious how you got your setup to work like it did.
2022-06-23 10:36 AM - edited 2022-06-23 10:37 AM
same issue here on kde, except there is no share on the other user's screen, but on the client everything looks like it's working
2022-06-22 09:36 PM - edited 2022-06-23 02:53 AM
Another data point: when running zoom 5.11.0 (3540) on Fedora 35 as a Wayland app under Wayland and Gnome 42, I find that I can screen share. However, there are problems with functionality still.
The worst of them is that once I start screen sharing. I cannot stop it! The floating toolbar that allows control of these things shows itself for only a few seconds, but then disappears and will not return! (I can only use Gnome to stop the screen sharing but that does not work well). Hopefully I am doing something wrong and there is a way to get this floating toolbar, or at least the major aspects of its functionality, back. (But I don't think I am doing anything wrong here)
Does anyone else see this behavior? (Or if not, can someone say how they stop sharing once they have started it?)
The above being said, it seems like the screen sharing can be used at this point (in my setup), since Zoom can be launched as an Xorg app within Wayland and running under XWayland, where the screen sharing now works and also, the floating toolbar does not go away. The screen sharing can be stopped and started at will within a single call. So I will probably be installing new Fedora distributions running Wayland on all my computers now.
2022-06-23 02:02 AM
Hey it seems to work now with the 5.11 version, thanks mates
2022-06-23 02:08 AM
After months of waiting for screen sharing to work under Wayland it is so disappointing do find that it only works with Gnome. Why is this? Do we have to wait many more months for it to be done properly so it works under KDE and other DEs? Can Brandon ask the developers why we have this restriction and how long it is going to take to fix it?
2022-06-23 03:50 AM - edited 2022-06-23 05:13 AM
After some testing (all Fedora 36 laptops on GNOME wayland) one crashes on screenshare with no apparent reason, can't figure out why since the setup is close to identical, any idea where to start? the logs just show a code 7 but no useful information it appears. Should I reach support or someone already has a workaround?
This seems like a driver issue, maybe
Module libedit.so.0 with build-id 786ebbe150c63e27beb2957d717bece33431af6f
Stack trace of thread 46419:
#0 0x00007f3572957f8d __memcpy_avx_unaligned_erms (libc.so.6 + 0x157f8d)
#1 0x00007f34ddd11b04 _mesa_GetTexSubImage_sw (iris_dri.so + 0x311b04)
#2 0x00007f34ddb7a1ad st_GetTexSubImage (iris_dri.so + 0x17a1ad)
After today's OS update, zoom doesn't seem able to recognise screens and windows on Wayland, just shares the main display whatever my choice is. Unfortunately this is not mature enough to excuse the cost for a license since there are other tools that work.
Will keep an eye though
2022-10-27 07:55 AM
2022-06-23 08:57 AM
Any eta for supporting other desktops on an API that supports all of them?
2022-06-23 08:58 AM
Zoom 5.11.0 uses a cross-desktop API. The restriction on GNOME is artificial now, rather than technical.
2022-06-23 09:39 AM
yes I know, I posted that numerous times above, I just wanted to keep this issue at the bottom
2022-06-23 06:43 PM
Was able to download the Zoom 5.11.0 (3540) release on Fedora 36 + Wayland, and in preliminary testing, it looks like it has proper support for screen sharing now!
2022-06-23 06:51 PM - edited 2022-06-23 06:51 PM
Don't give a picture to zoom that it's finished and working it still doesn't work on every other desktop due to an arbitrary restriction that they have to remove. People posting that is working will make zoom less likely to fix the issue
2022-06-24 12:51 AM
But we do need to give realistic feedback about what works and what doesn't, to give them the best possible understanding of where they stand, right? It's now working under some circumstances - that's huge progress, even if we are not entirely there yet.
2022-06-29 12:46 PM
No offense, but that is a very untrue statement. Zoom has teams of developers dedicated to solving issues such as this one. We just have to prioritize like any other software company on the market.
2022-06-30 03:44 AM - edited 2022-06-30 03:45 AM
thanks for the response, I was pretty concerned that nobody from zoom was responding for a reason similar to that
2022-06-30 07:09 AM
To give you an understanding of how important this topic is to us here at Zoom. This topic has been the number 1 trending topic on the Zoom Community page since it started. Nearly every Zoom Community Champion reads this thread. Trust me when I say that we want this completely solved just as much as the Linux community does. We bring this thread up in our meetings every single time. I am in near constant communications with the developers. I may be the POC on this thread but there are many Zoom eyes on this thread. Including the lead developer.
I say all of this to give you all peace of mind that we do completely care about every issue that is posted on the Zoom Community page. That is why we built this page.
2022-10-28 09:23 AM
I apologize about the delay with me now. I started a new role back in July and it is keeping me even more busy than I used to be. I am going to DM you about something that I would like to discuss with you.
2022-07-01 10:55 AM
"it has proper support for screen sharing now!"
How do you stop sharing a screen though?
Are you saying you can do this in Fedora 36 and gnome? I cannot do it in Fedora 35. The toolbar disappears and will not come back. Are you sure your zoom is running under Wayland and not XWayland? I find it works under XWayland but not under Wayland.
2022-06-24 12:54 AM
Alright, 5.11.0 is a huge step forward for me. Using openSUSE Tumbleweed 64 bit (GNOME etc), I can now share entire screens without the unsafe_mode workaround, I can share individual windows (even if they are not currently visible on my desktop), and, most importantly, I can now do the same in a webinar, where previously not even the workaround helped. I checked this in actual meetings to verify that the actual content is being shared, not just a grey rectangle or anything. Thanks to zoom for *finally* fixing this - even though it sounds like there is some more work to do for other platforms.
2022-06-24 01:05 AM
Agreed. It's very important to give feedback on THIS ISSUE.
Those with problems on other Linux platforms should feel free to start a new thread. It's important to note flaws in the solution for this issue and not others.
2022-06-24 08:37 AM - edited 2022-06-24 08:59 AM
flaws in others? idk about that, but what I do know is that I am going to start a new thread
track progress here: https://community.zoom.com/t5/Meetings/Screensharing-only-works-on-GNOME-wayland-when-it-should-work...
2022-06-25 06:22 AM
This is just ridiculous. I'm on Gnome, an Arch-based distro (EndeavourOS), zoom updated to 5.11, and it still doesn't let me share because of some artificial limitations...
I'll leave it without further comment because I have nothing nice to say about those developers working for zoom.
2022-06-30 11:57 AM
still broken on kde & other desktops 5.11.1