Open MirandaStreeter opened 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.
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
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
Here is a community discussion about the issue. No resolution.
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.
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...
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
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.
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 sharingZoom 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.
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?
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.
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
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.
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.
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?).
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:
.deb
Package to the selected Version 6.x.y.abc
: https://zoom.us/client/6.x.y.abc/zoom_amd64.debsudo apt install <download-path>/zoom_amd64.deb
command
When clicking the "Share" button at the bottom during a zoom meeting, only the following shows:
And the following appears in the journal:
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:
zoomus.conf
file'senableWaylandShare=true
is setzoomus.conf
file'sxwayland=true
parameter is flipped tofalse
XDG_CURRENT_DESKTOP
environment variable tognome
does not make a difference: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.