share screen linux wayland broken | Community
Skip to main content
Newcomer
June 18, 2024
Solved

share screen linux wayland broken

  • June 18, 2024
  • 60 replies
  • 70 views

Hi, I just installed Zoom client 6.1 on openSuSE and screen sharing is not showing any option anymore on Basic, but only under Advance tab, and there in this one I can only select Screen Portion, but also cannot confirm the screen sharing. Please fix it or let me know how to downgrade to previous version. Thanks in advance!

Best answer by freeseek

I agree with @justifru as the following workaround:

 

 

sudo apt install cinnamon lightdm sudo dpkg-reconfigure lightdm

 

 

then selecting lightdm and then restarting fixed the problem for me on Ubuntu 24.10

60 replies

Newcomer
August 8, 2024

Any updates on this? Wayland screen sharing breaks every other release. I am able to share the first time, but if I stop sharing or join a new meeting, the screen share is blank for all following sessions until I restart zoom

Fedora 40
Gnome
Wayland

Newcomer
August 8, 2024

@B-DigitalI've found that when Zoom crashes after stopping to share, I had to kill the aomhost process that was left behind. Then I could get virtual backgrounds to work again and sharing. This is not sustainable but in a pinch it helps.

Newcomer
August 8, 2024

I'm on KDE Neon (which is ubuntu) with plasma 6 which is running 6.1.5.871 that is still getting the only support GNOME message.

Newcomer
August 8, 2024

Hm. It's weird. I'm on KDE Neon 6 and all works fine with 6.0.12. The newer versions broke the sharing, but even zoom 6.1.6 don't require Gnome.
Here you can download and check https://zoom.us/client/6.0.12.5501/zoom_amd64.deb

Newcomer
August 8, 2024

Downgrading to 6.0.12 seems to allow share to attempt, and i get the prompt to choose a screen or window, but i don't think its actually sharing (zoom doesn't disappear and i don't get the shared screen version of controls).

Newcomer
August 12, 2024

Still crashes after stoping a screen share with Zoom 6.1.6 on Arch:

$ pacman -Ss pipewire | grep installed
extra/libpipewire 1:1.2.2-1 [installed]
extra/libwireplumber 0.5.5-1 [installed]
extra/pipewire 1:1.2.2-1 [installed]
extra/qemu-audio-pipewire 9.0.2-1 [installed]
extra/wireplumber 0.5.5-1 [installed]

I can't work right now with Zoom and it's hard to downgrade on Arch. Please fix this as soon as possible.

 

Newcomer
August 17, 2024

It would be great to get some communication on this; there were 2 different releases which we were told to solve the problem, neither of which did so, and it has been nearly a month since the July 22nd fix. I don't mind so much that stuff like this breaks(it happens), but it is quite frustrating when there is no communication about when/if something will be fixed. If the previous releases weren't going to fix this bug, then it would have been great if we could know beforehand so that we can make informed decisions on what to do.

It seems that you are planning on fixing it, so I would just like to know what has been causing such a big delay in fixing this, and what can we expect moving forward on this issue?

Newcomer
August 19, 2024

In my case with Zoom 6.1.10 under Fedora 40 KDE 6.1.4 the symptoms are different. "Use system desktop capture" and "Use system window capture" both do the same thing and result in a prompt from KDE to allow remote control. On agreeing to this a share of the entire desktop (three physical displays) starts. Trying to edit what is shown a window titled "Select a window or an application that you want to share" opens. Moving the mouse pointer over the preview in this achieves nothing despite the "Hover over preview to edit" prompt. The Share sound and Optimize for video sharing options are unselectable. On the plus side, Zoom doesn't crash when I stop the share.

Newcomer
August 26, 2024

I am in the same boat.

Newcomer
August 19, 2024

The Share sound and Optimize for video sharing options are unselectable. I am also facing the same issue when I am playing a webinar. How to fix this?

Newcomer
September 9, 2024

I have been stuck using an older version of zoom until the fix it.

Newcomer
September 9, 2024

Can you share which version you are using, I will have to do the same

Newcomer
August 28, 2024

Just installed zoom 6.1.11 (1545) and whenever I stop sharing it hangs. I'm using Arch Linux with the following pipewire libraries installed.

 

$ pacman -Ss pipewire | grep installed
extra/helvum 0.5.1-1 [installed]
extra/libpipewire 1:1.2.3-1 [installed]
extra/libwireplumber 0.5.5-1 [installed]
extra/pipewire 1:1.2.3-1 [installed]
extra/pipewire-alsa 1:1.2.3-1 [installed]
extra/pipewire-audio 1:1.2.3-1 [installed]
extra/pipewire-docs 1:1.2.3-1 [installed]
extra/pipewire-pulse 1:1.2.3-1 [installed]
extra/qemu-audio-pipewire 9.0.2-1 [installed]
extra/wireplumber 0.5.5-1 [installed]

 

This is what is in the zoom_stdout_stderr.log file at the end of the session when it dies:

 

*** pw_stream_set_active called from wrong context, check thread and locking: Operation not permitted
*** impl_ext_end_proxy called from wrong context, check thread and locking: Operation not permitted
'this->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:62 do_unlock()
zoom was exited due to a handled signal: 9
ZoomLauncher exit.

 

Newcomer
September 4, 2024

Same here. Please prioritize this. I have currently to tell that MS Teams is working better than Zoom.

Newcomer
September 16, 2024

Dear Zoom Team,


you really must think the worst about us Linux users, don't you?
I really could not imagine how the situation could get any worse, but yet here we are. With Update 6.2. not only the incompatibility issues with Pipewire 1.2.x have not been addressed at all, but now the little fraction screen sharing that was working for me (full desktop with crash once I stop sharing) is also broken, since half of the screen is blurred with the latest update. 

 

You have been made aware of the incompatibility, almost 3 months ago. The Pipewire team claims v1.2 to be fully ABI/API compatible with former 1.x releases.

I mean, I even don't get why you break the somewhat working sharing solution from the 5.x branch on purpose. But that you're unwilling of fixing a show stopping bug, that basically locks out all users not running an ancient Debian release, that is truly beyond my understanding.

 

Thank you for your great work.

Ray_Harwood
Community Super Champion | Customer
Community Super Champion | Customer
September 16, 2024

Greetings, all!

 

Zoom dropped version 6.2.0 today. Check the Release Notes for information.


The format of the Release Notes has recently changed. The current set of notes is in a table format, and the multiple documents (one per OS) have been consolidated into one, with a column indicating which OS each change applies to. 

 

I have no details or inside information about it and I’m not a Linux user – just a helpful messenger!

Newcomer
September 16, 2024

6.2.0 does not fix any problems I am having. It still only shares all screens instead of only one screen or window. For now I am still stuck on Version 5.17.11 (3835). But thank you for sharing I will be back to try 6.3 or what ever version is next.

Newcomer
September 17, 2024

Ok, well it's clear the situation remains unchanged even with 6.2.0.1855.  @MGSR and @Ray_Harwood thank you for your attention.  It truly is appreciated you two are engaged and reading along.

 

The status is that 6.2.0.1855 still does not raise the window selector, it only shares the entire desktop, with all monitors.  Zoom also freezes when stop sharing is clicked.  All of this is captured in @Salgir 's post here: 

 

https://community.zoom.com/t5/Zoom-Meetings/share-screen-linux-wayland-broken/m-p/191958/highlight/true#M106154  

 

wherein he actually opens a ticket, provides the info, and the ticket is automatically closed.  NOT ENCOURAGING!

 

That said, I have a workaround.  It's insane, and potentially not applicable to everyone, but it "works for me," primarily because it does not rely on the zoom client!

 

Many of you may know where this is going...

 

1.  Set up OBS.

2.  Configure a virtual camera (v4l2loopback).

3.  Create a scene with a pipewire based window capture.

4.  Use it to capture whatever window you like.

5.  Stream the scene to the virtual camera.

6.  In zoom, change your camera to the virtual camera.

 

You are now screen sharing to your zoom meeting.  You can use meeting configs to temporarily spotlight your window, or spotlight yourself if you are the host.

 

Anyway, it's ridiculous that we have to do this, but this works.  It's a hacky workaround, but we are linux users.  It's what we do.

Newcomer
September 18, 2024

Well, I already shared my own thoughts on this. The issue for me is, my employer is paying for Zoom, so we expect issues to be sorted out in a reasonable timeframe. 

Nevertheless, I created a support ticket and shared all information about the issue, and also pointed to this thread. They gave me some workaround instructions, which more or less are quite the same as your suggestion. There is only one big difference. Instead of switching the primary camera feed, just use screen share and under the "advanced tab", use "content from 2nd camera". For whatever reason, the screen share will open in full screen, but you can simply double-click on it and tame it back into a normal window.
Important! The OBS virtual camera must be activated BEFORE you start Zoom. Otherwise, Zoom won't recognize it. 

 

Better instructions can be found here: https://support.zoom.com/hc/de/article?id=zm_kb&sysparm_article=KB0059085


This method for screen share will NOT trigger the Pipewire issue when being stopped. So all in all, this is quite a functional workaround, and we're back to annoyance/inconvenience. 

 

This just lets us behind with one open question. If the Zoom Team/Devs are aware of the fact, that the OBS guys did the Pipewire screen capture thing properly, why not just look into their solution, and fix the own one?