KDE/Wayland - Zoom v6.x cannot share individual windows

MirandaStreeter commented 2 months ago

When clicking the "Share" button at the bottom during a zoom meeting, only the following shows:

And the following appears in the journal:

Aug 21 13:06:26 <hostname> kwin_wayland[1083]: kf.windowsystem: static bool KX11Extras::mapViewport() may only be used on X11

If I click "Use system window capture" and click "Share", instead of the normal portal selection for windows I get the following popup:

This is a permissions popup from the xdg-desktop-portal-kde backend. If I click "share" I don't get to pick any window, but instead my entire desktop spanning all monitors is shared, and the "Remote Desktop" tray icon is made available:

If I were to get a popup I would expect to instead be presented with a selection of screens/windows via the portal to pick from, like so:

The above is an example using a different screen sharing application running via flatpak, meaning the issue is likely not an issue with KDE itself.

More details:

There are no other relevant logs in the journal I can see
My zoomus.conf file's enableWaylandShare=true is set
Under Settings > Share Screen > Advanced I have "Screen capture mode on Wayland" set to "Pipewire Mode"
This used to work under Zoom v5.x
The same issue occurs with or without the KDE "XWayland Video Bridge" service running
The same issue occurs regardless whether the zoomus.conf file's xwayland=true parameter is flipped to false

Setting the XDG_CURRENT_DESKTOP environment variable to gnome does not make a difference:

$ cat ~/.local/share/flatpak/overrides/us.zoom.Zoom 
[Environment]
XDG_CURRENT_DESKTOP=gnome

Despite the "Remote control requested" popup, this doesn't look or act like a real remote control session. The same behavior also happens whether or not the setting is enabled:
I've been able to reproduce this on both Fedora KDE 40 and latest Arch as of 2024-08-21

To reiterate in case it isn't clear, this is sharing all my desktops at once no matter what I select! For my dual 4k display setup this is quite unusable for any viewer.

I'd love if someone else could verify this happens to them on KDE Wayland w/ Zoom v6.x and confirm this isn't some odd issue with my account settings.

qu-jieniu commented 2 months ago

Same! I tried installing the latest rpm from zoom.us but also having the same issue, so the issue might not be related to flatpak. I do recall there's a working version.

MirandaStreeter commented 2 months ago

If it's not a flatpak issue then I'm quite confused. It sounds like it works fine on Gnome, but it should all be using the same protocols and pipewire captures. Is there someone on the latest LTS KDE (v5.27.x) that can try out Zoom v6.x and verify whether it works or not?

If it works on an older KDE then there's something to bug them about.

If it still doesn't work and the issue is upstream then I'm curious if there's something hardcoded that we can work around with a bit of a hack ala #474

StarkZarn commented 2 months ago

If it's not a flatpak issue then I'm quite confused. It sounds like it works fine on Gnome, but it should all be using the same protocols and pipewire captures. Is there someone on the latest LTS KDE (v5.27.x) that can try out Zoom v6.x and verify whether it works or not?

If it works on an older KDE then there's something to bug them about.

If it still doesn't work and the issue is upstream then I'm curious if there's something hardcoded that we can work around with a bit of a hack ala #474

I can confirm that on Debian sid and KDE Plasma 5, the latest zoom 6.1 has the exact issue described here.

The only way I was able to regain support for individual window share was by downgrading to 6.0.X with the following flatpak command, you're welcome to reference the commit if desired. sudo flatpak update --commit=b9505f108b5f9acb2bbad83ac66f97b42bc6a75b9c28ed7b75dec1040e013305 us.zoom.Zoom

StarkZarn commented 2 months ago

https://community.zoom.com/t5/Zoom-Meetings/Screen-sharing-a-single-window-is-not-possible-on-KDE/m-p/195580

Here is a community discussion about the issue. No resolution.

MirandaStreeter commented 2 months ago

The only way I was able to regain support for individual window share was by downgrading to 6.0.X

I can confirm that works!

Dang. I suppose I'm curious what it is about 6.1 on Gnome that works but not on KDE. I thought the dust had settled after they switched from org.gnome.Shell.Screenshot to org.freedesktop.portal.ScreenCast so I'm surprised it's broken again. I'm guessing the Zoom team has some internal Jira ticket floating around at a low priority as they seem to only officially support Gnome. I recall without flipping certain settings/environment variables you get the following message:

Can not start share, we only support Wayland on GNOME with Ubuntu 17 and above, Fedora 25 and above, Debian 9 and above, CentOS 8 and above, OpenSUSE Leap 15 and above, Oracle Linux 8 and above, RHEL 8 and above, Mageia 7 and above, Arch Linux, AnterGos, Manjaro. If your OS is not on the list, please use x11 instead.

That was part of the long saga with #22.

The downgrade is a decent workaround in the meantime, but I don't imagine the client will be compatible with Zoom services forever and long term I'm unsure what to expect from the Zoom team.

sand-r commented 2 months ago

Screen sharing is completely non-functional on sway and I think this issue could have the same rootcause as they broke in the same update. if I were to guess zoom is relying on something that only gnome implements, just like they used gnome specific implementation for screen sharing on wayland before they moved to xdg-desktop-portal backend.

The irony is that zoom is completely unusable on gnome as well if you are using virtual desktops. Once your meeting is minimized you cannot maximize the window again and you are forced to reconnect...

ettancos commented 2 months ago

Screen sharing is completely non-functional on sway and I think this issue could have the same rootcause as they broke in the same update. if I were to guess zoom is relying on something that only gnome implements, just like they used gnome specific implementation for screen sharing on wayland before they moved to xdg-desktop-portal backend.

for me it seems like that it is failing right after trying to use the org.freedesktop.portal.RemoteDesktop protocol that is so far not implemented in xdpw/xdph and zoom being zoom it is not handled very gracefully (6.1.11, hyprland)

I know its the kde thread, to not be completely off-topic: it might help to debug to check the dbus conversation while sharing

sand-r commented 2 months ago

Screen sharing is completely non-functional on sway and I think this issue could have the same rootcause as they broke in the same update. if I were to guess zoom is relying on something that only gnome implements, just like they used gnome specific implementation for screen sharing on wayland before they moved to xdg-desktop-portal backend.

for me it seems like that it is failing right after trying to use the org.freedesktop.portal.RemoteDesktop protocol that is so far not implemented in xdpw/xdph and zoom being zoom it is not handled very gracefully (6.1.11, hyprland)

I know its the kde thread, to not be completely off-topic: it might help to debug to check the dbus conversation while sharing

Zoom indeed is trying to query for org.freedesktop.portal.RemoteDesktop. I tested with a fork of xdg-desktop-portal-wlr which implements RemoteDesktop and I was able to pick the output to be shared, but Zoom completely crashes right after I select the output. I guess we will have to wait until this is implemented on wlr based wms and hope that it will actually work.

StarkZarn commented 1 month ago

Screen sharing is completely non-functional on sway and I think this issue could have the same rootcause as they broke in the same update. if I were to guess zoom is relying on something that only gnome implements, just like they used gnome specific implementation for screen sharing on wayland before they moved to xdg-desktop-portal backend.

for me it seems like that it is failing right after trying to use the org.freedesktop.portal.RemoteDesktop protocol that is so far not implemented in xdpw/xdph and zoom being zoom it is not handled very gracefully (6.1.11, hyprland) I know its the kde thread, to not be completely off-topic: it might help to debug to check the dbus conversation while sharing

Zoom indeed is trying to query for org.freedesktop.portal.RemoteDesktop. I tested with a fork of xdg-desktop-portal-wlr which implements RemoteDesktop and I was able to pick the output to be shared, but Zoom completely crashes right after I select the output. I guess we will have to wait until this is implemented on wlr based wms and hope that it will actually work.

That seems certainly related, but I don't think that will fix the original issue at hand here. Ultimately, Zoom has introduced a regression which needs to be fixed.

takluyver commented 1 month ago

I have no reason to think this will be fixed, but does anyone on KDE want to test the Zoom 6.2 update, which is prepared in PR #481?

paidhi commented 1 month ago

I see the same issue with the official RPM from the Zoom website on Fedora 40 (6.2.0-1855). Downgrade to 6.0.10-5325 works for me as a workaround.

w10have commented 1 month ago

I was a very happy Linux zoom'er under Fedora 40 prior till moment my workstation was updated to plasma-workspace-wayland-6.1.5... I do not remember which version I was on exactly, I figure 6.0.xyz and everything was working like a charme.

Now with latest I see exactly this problem too. And it frustrates me to the max.

I understand that my comment doesn't contribute to the problem, I only hope a fix is made asap.

zoom-6.1.11.1545-1.x86_64

yakovpol commented 3 weeks ago

The only working solution I have found so far is downgrade. Zoom version 6.0.12 (5501) works as it should on Kubuntu 24.04.1 with Wayland.

lightdiscord commented 3 weeks ago

I'm trying to implement the window/screen selection on xdg-desktop-portal-kde since the selection is not implemented for Remote Desktop sessions but only for ScreenCast sessions (Zoom switched between both of them recently). It works but I'm hitting a bug where Zoom freezes when the session ends (at Zoom requests or when the window is closed or the session is closed via Plasma).

I didn't have a lot of time recently to investigate the issue, if anyone has any idea where the problem could come from I'd be happy to hear it.

takluyver commented 3 weeks ago

I have seen people on the Zoom forums complaining about a similar sounding issue when you end screen sharing, and saying it's an incompatibility with a newer version of Pipewire (1.2?).

JeffreyAnimal commented 5 days ago

If it's not a flatpak issue then I'm quite confused. It sounds like it works fine on Gnome, but it should all be using the same protocols and pipewire captures. Is there someone on the latest LTS KDE (v5.27.x) that can try out Zoom v6.x and verify whether it works or not? If it works on an older KDE then there's something to bug them about. If it still doesn't work and the issue is upstream then I'm curious if there's something hardcoded that we can work around with a bit of a hack ala #474

I can confirm that on Debian sid and KDE Plasma 5, the latest zoom 6.1 has the exact issue described here.

The only way I was able to regain support for individual window share was by downgrading to 6.0.X with the following flatpak command, you're welcome to reference the commit if desired. sudo flatpak update --commit=b9505f108b5f9acb2bbad83ac66f97b42bc6a75b9c28ed7b75dec1040e013305 us.zoom.Zoom

I can confirm downgrading to 6.0.x works.

For downgrading Zoom on Debian I did the following:

Searched on the Releases-Page for the Workspace-App and selected a available Version (in my case: 6.0.12 (5501)).
Edited the Download-Link of the .deb Package to the selected Version 6.x.y.abc: https://zoom.us/client/6.x.y.abc/zoom_amd64.deb
Downloaded file and installed the package by the usual sudo apt install <download-path>/zoom_amd64.deb command

flathub / us.zoom.Zoom

KDE/Wayland - Zoom v6.x cannot share individual windows #477