Wayland screen sharing broken with GNOME 41 on Fedora 35 | Community
Skip to main content
Newcomer
November 4, 2021
Solved

Wayland screen sharing broken with GNOME 41 on Fedora 35

  • November 4, 2021
  • 94 replies
  • 6 views

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.

Best answer by dalewe

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/67283/highlight/true#M35878 provides a workaround for the issue, which has to be fixed by Zoom!

94 replies

Newcomer
January 9, 2022

Hello,

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 🙂

 

 

Newcomer
March 23, 2022

Hello!

 

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!

 

Cheers

Newcomer
March 23, 2022

Very well stated!

Newcomer
January 12, 2022

 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.

Newcomer
January 13, 2022

Please fix it Zoom!

Newcomer
January 14, 2022

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.

 

ngompa_datto
Newcomer
Newcomer
January 19, 2022

Hello @YaBoiB,

 

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.

YaBoiB
Community Champion | Employee
Community Champion | Employee
January 20, 2022

Hello @ngompa_datto

 

 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. 

Newcomer
January 19, 2022

Sorry,  duplicate reply...

Newcomer
January 21, 2022

Chiming in to report same issues with Slackware x86 and x64 Current and OpenSUSE 😞 - please add wayland support!  Thanks

YaBoiB
Community Champion | Employee
Community Champion | Employee
January 22, 2022

Hello All, 

 

 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. 

Newcomer
January 22, 2022

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 5.9.1.1380 (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.

Newcomer
January 24, 2022

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.

Newcomer
January 24, 2022

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.

YaBoiB
Community Champion | Employee
Community Champion | Employee
January 25, 2022

Hello, 

 

 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. 

Newcomer
January 25, 2022

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?

feaneron
Newcomer
Newcomer
February 1, 2022

Hi @YaBoiB 

 

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.

 

With respect,

Georges

ngompa_datto
Newcomer
Newcomer
February 2, 2022

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?

feaneron
Newcomer
Newcomer
February 2, 2022

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.