Wayland screen sharing broken with GNOME 41 on Fedora 35

[intrlocutr]

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.

[iszekely]

Hi @YaBoiB,

Sorry for the late response. I tested 5.11.9 as well and it works. Also tested 5.11.3 and 5.11.1 and both seem to work, too. I must have been something intermittent issue I had last time. Others also complained about occasional black screen while sharing and they said that restarting Zoom solved it for them.

Thank you for the fixes and for following up with us.

[roebel]

Hello @YaBoiB,

being on ubuntu 22.04 (all updates applied) with gnome/XWayland following all the steps discussed above I finally am encountering  the situation reported by @iszekely as

"and the participants complain that they can only see a black screen."

I tried zoom versions 5.12.0 and 5.11.9 and both act the same. I restarted the computer and restarted the apps a few times. and nothing changes. I debugged this a little bit further connecting to my session running in the zoom app with a zoom session running on the same computer in firefox. It turns out that using this setup firefox can share a window and the zoom application correctly displays it. It does not work the other way around. So it seems there is still a glitch in the zoom app with Wayland. Do you have any ideas about what I may have to change?

Thanks

[YaBoiB]

@roebel, 

 I do not. I honestly detached from this issue a bit when I got a new role here at Zoom. Let me jump back in and see what the Engineers are saying now about this issue and I will report back to you with what I find. Have you attempted to use XOrg and run into the same issues? @idkman  has been a great source of education for this thread for me. (Thank you) I only have a VM with Linux based products that I honestly do not use that often. Only when their is an issue that customers bring up. My main machines are Windows and Mac OS based. 

Let me see what I can find out for you. 

Thanks, 

Brandon 

[dalewe]

For everyone trying to share their screen on wlroots based compositors - I found a workaround and to be honest it tells quite a bit about how "dedicated" zoom is to this feature:

Zoom relies on the VideoCrop metadata to be set on the pipewire buffer. This is not required if the whole buffer is to be shared and only Gnome sets this anyways.  Using this patched version of xdg-desktop-portal-wlr makes Zoom work: https://github.com/David96/xdg-desktop-portal-wlr/tree/zoom-fix

A similar hack should be easy to add to the KDE portal, too.

It's crazy a simple fix like this can take Zoom that long…

[chutchins]

Thats awesome! Thank you for putting it together, I can't really use it but I believe thats because if I trick zoom into thinking i'm on gnome it cannot find my dbus session because it's under 'sway' not 'gnome'. Or at least that's my best guess why it always complains when I try to trick zoom into thinking I'm running gnome. But I think I'll figure that out soon, I cannot wait to try your patch! You should put an MR against the upstream repo if you haven't already.

[dalewe · Accepted 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!

[chutchins]

Sounds good, nonetheless thanks for the hotfix. Again, I'll try to figure out why my system in particular is not working as expected but thank you. Traditionally I just run "XDG_CURRENT_DESKTOP=GNOME zoom" but no such luck at the moment. I'm sure there's going to be more to the puzzle as there always is.

[YaBoiB]

@dalewe, 

 Thanks so much for helping with this issue. We appreciate the collaboration. 

Regards,

Brandon

[dalewe]

Not sure why my previous reply was marked as solution, it didn't contain any. The solution would be for Zoom to finally roll out the trivial fix of not relying on the pipewire VideoCrop property to be sent. It's extremely disappointing to see that even when directly presented the solution, Zoom is not able to roll out a fix within weeks/months.

[YaBoiB]

@dalewe, 

 I marked it as a solution. It is a solution to a workaround until Zoom developers can resolve it. Please know that our developers have much to consider before we just "roll" out a fix. They have checks and balances and compliance and security that a "fixed" code would have to go through before being released. You may think that it is a simple solution, but we must look at it from a different perspective.

If you would like to work with our Engineers on this issue, please submit a Support ticket and work with our team. That is our process for solving issues such as this one. 

Thanks, 

Brandon 

[johnfparis]

I agree that the post by @dalewe should not be marked as a solution; among other things, it does not address the specific OP, which was Zoom using GNOME 41 under Wayland.

The first correct post that this issue was resolved with Zoom 5.11 is this:

https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/...

[YaBoiB]

@johnfparis, 

 Thank you for your input but the 5.11.x fix for GNOME 41 is working as designed. What we are talking about now is for GMOME 42 and the Zoom Engineers are aware of this and are working on a solution. We can still conversate about the issue on 42 while the accepted solution button is engaged. It does not thwart the thread. I just want to make sure that any other users looking for answers about GMOME 41 screen sharing issues have the ability to find this thread. 

Regards,

Brandon

[jewing]

Just upgraded from Fedora 35 to Fedora 37 with Gnome 43 and tried Zoom 5.12.6(173).  Zoom Share option to "Use System Capture" (which was there on Fedora 35) was no longer available.  Also the Speaker & Mic options of "Same as System" didn't work, but selecting the actual hardware speaker & mic worked.   The circumvention of executing Zoom with 
"env XDG_CURRENT_DESKTOP=GNOME <your-path-to-zoom"
fixed both problems;  but what was really unexpected, it also fixed the problem when invoking Zoom by the way that failed before, and the direct invocation from the desktop continues to work across a power-down/power-up.   After being told once, Zoom must be saving as application data that my user session is in a Gnome environment.  That suggests that different saved content in the user's .zoom directory might explain why some have trouble replicating the failure.

[sayap]

Wow, I tried the same fix in kwin, and now I can actually share screen with KDE. Thanks!

(https://gist.github.com/sayap/f343bff7700d45b555aea7e581097314 - I have no idea what I am doing here, but it seems to work)

[dalewe]

Glad it works 🙂 I think you forgot to increment the number of params for pipewire, it now probably discards the header param, since it comes after the videocrop.

[sayap]

Ah right, updated the gist and recompiling... Thanks again 😁

[idkman]

I tried that patch it's working great! (I applied it on stable kwin using a modified pkgbuild from the svntogit repo thing for arch)

[kplaha]

@idkman would you mind sharing more detail about the steps for arch linux? Thanks.

[charles-d-burto]

I'm still seeing an issue on Ubuntu 22.04.1 with Zoom 5.11.3.  If I'm in a wayland session the only options I have for screen share is System Capture Device.  This is actually a regression for me because I could at least share an entire screen prior to this release.

[johnfparis]

When I double-click on "Use System Capture" I am taken to a new screen offering the options of "Single Window" or "Entire Screen". Are you not seeing that?

[johnfparis]

I have uncovered a glitch in the new screen share. When I want to terminate sharing a single window, Zoom leaves me in screen sharing mode. The only way to terminate the share is to close the application window, or else to quit Zoom entirely and re-enter.

The workaround is to close the application window, then terminate screen sharing. This is not very good, especially if I want to keep the window open on my own computer while no longer sharing it. But at least it's better than having to shut Zoom down entirely.

[idkman]

Looks like zoom has finally fixed the screensharing issue, I am using KDE plasma 5.25.4, and with the latest zoom (5.11.9), screensharing works as intended without any patches to kwin

env variable workaround is also no longer needed!

Thanks Zoom!

[Bort]

There were quite a few screen sharing related fixes in this release, so I'm glad to hear its working for you! 

[johnfparis]

The most recent release also fixes the issue I raised (screen sharing wouldn't stop unless I closed the window being shared). Thanks.

[YaBoiB]

Hello @johnfparis, 

That is great news. This thread has been so helpful in resolving many users issues with regards to screen sharing over Linux. Special thanks to @idkman who has been a huge help for me personally. 

Regards, 

Brandon 

[kplaha]

Hey @idkman that's awesome to hear. Which distribution are you using? I tried the latest zoom on openSUSE and it is not working yet. I get the following error(s):

xdg-desktop-portal:

xdg-desktop-por[7531]: A backend call failed: Message recipient disconnected from message bus without replying

Also, the plasma-xdg-desktop-portal service has this:

plasma-xdg-desktop-portal-kde.service: Main process exited, code=dumped, status=11/SEGV
plasma-xdg-desktop-portal-kde.service: Failed with result 'core-dump'.

Finally, dbus-daemon complains:

dbus-daemon[3529]: [session uid=1000 pid=3529] Activating via systemd: service name='org.freedesktop.impl.portal.desktop.kde' unit='plasma-xdg-desktop-portal-kde.service' requested by ':1.104' (uid=1000 pid=7531 comm="/usr/libexec/xdg-desktop-portal")

Thanks.

[idkman]

I was using arch linux

[jung]

Does it still work for you with 5.26.0? I tried downgrading to Zoom 5.11.9 and 5.11.10, but still see the problem: when I select "use system capture", absolutely nothing happens.

[idkman]

Congrats zoom, you guys have broke it AGAIN. 

I honestly don't know what to say without cussing the heck out of the dev team, so I will just leave it at that. 

broken with zoom 5.12.0, I am currently in a meeting, so I cannot test with the XDG_CURRENT_DESKTOP workaround, but it's disappointing to see this kind of stuff happen because of the lack of testing and code reviewing in the linux client. 

Even if you do test it, you are not reviewing the code correctly and you are only testing on one DE, not even two. 

[YaBoiB]

Hello @idkman, 

 Give me some time. I am talking to the Devs right now. I am going to open a new Engineering ticket based on this post and see what I can find out about the 5.12.0 release. I will let you all know what I find out here as soon as I can get some feedback. Apologies for the issues that you are facing. 

Regards,

Brandon Welch

[indyx1]

This is STILL BROKEN on Version: 5.12.2 (4816)

Any updates on when you will finally support Linux again? This has been a very long and bad experience of things relating to screen sharing not working

(screen sharing dialog comes up, when I share a window/screen it looks like I'm sharing but everyone else just sees spinning circle and "<name> has started screen sharing" and then just black window)

[YaBoiB]

Hello All, 

 The Team has advised me that any users with this issue should submit a support ticket and work with the Technical Support Engineers on gathering logs and we can work on these issues on a case-by-case basis. 

Thanks,

Brandon 

[YaBoiB]

Hello All, 

 Did you all get an email about this support article? https://support.zoom.us/hc/en-us/articles/9836712961165 I got this today since I am an admin of another account on Zoom, so I wanted to share it with all of you in the case that some of you may not have gotten the email. I think it was sent out to only admins and owners of accounts. 

Thanks,

Brandon 

[idkman]

fortunately, the workaround does work, so that's a plus

but there is some problem in the dev team interonally that caused this pop up to come back in 5.12.0

[jung]

> fortunately, the workaround does work, so that's a plus

Which work-around? I tried setting "XDG_CURRENT_DESKTOP=GNOME" but that did not make any difference.

[kd2eat]

Just a "Me too" with this problem.  It still exists as of late November.  Fedora 36, Wayland, Gnome.  I'm getting the "frozen on screen share" issue reported above.  I'm running Zoom 5.12.6 (173).  Per request from Zoom support above, I've submitted a support ticket.

[kd2eat]

I take it  back.  They bounced my support ticket because I didn't use my login's email address.  When I DO use my login, they take away my ability to submit a ticket.  Awesome.  Not.  I guess I'll just keep complaining here.

[YaBoiB]

Hi @kd2eat, 

 I can create a support ticket on your behalf. I will work on that now and let you know. 

Brandon

[kd2eat]

Brandon, Thank you.  I use Zoom/Linux on my home computer, though I use it on Windows through my employer-provided laptop.  I was trying to segregate the bug report to my personal zoom account, since it wasn't on an employer-provided system, but was restricted.  Anyway, if you need more data on this issue via Fedora Linux, I'm watching this thread and can run tests if required.  Thanks, Mike

[JHBoricua]

Why is this idiotic check still a thing? I run Nobara 36, which is essentially Fedora 36 with some gaming specific tweaks built in. But no, you're not running 'Fedora' so we are simply not going to allow you to screenshare despite meeting all the requirements. FFS guys, get rid of this artificial gate. I wonder how many issues would be resolved by eliminating this.

And fix your darn PWA too if you want to push it as an alternative. There, I can screen share but I can't see chat messages in Team Chat unless I happen to have the person/group in focus. Otherwise, I can see the bubble indicators showing new messages from a person/group in Team Chat, but when I click on them, it doesn't display the messages. What a joke.