Package Details: zoom 7.0.0-1

Git Clone URL: https://aur.archlinux.org/zoom.git (read-only, click to copy)
Package Base: zoom
Description: Video Conferencing and Web Conferencing Service
Upstream URL: https://zoom.us/
Keywords: call conference meeting video
Licenses: LicenseRef-zoom
Replaces: zoom-libs, zoom-libs-bin
Submitter: edh
Maintainer: edh (gromit)
Last Packager: edh
Votes: 730
Popularity: 7.47
First Submitted: 2015-08-15 13:18 (UTC)
Last Updated: 2026-03-26 02:00 (UTC)

Pinned Comments

erbrecht commented on 2024-11-19 13:06 (UTC)

@Rhinoceros - I finally got screen sharing to work under KDE with Wayland. Looks like I'm using the same versions as you:

  • Zoom 6.2.10
  • pipewire 1.2.6

I followed the Screen share section on the Zoom wiki page:

https://wiki.archlinux.org/title/Zoom_Meetings

The only thing I didn't need to do was set XDG_CURRENT_DESKTOP=gnome. I followed the other steps, and now I can choose my desktop/window to share. Prior to following the wiki I couldn't stop screen sharing without the hanging issue, which I was experiencing prior to 6.2.10.

edh commented on 2016-08-26 11:03 (UTC) (edited on 2017-03-09 10:48 (UTC) by edh)

I contacted the zoom support on 13th July 2016 and tried to lure them into creating a proper PKGBUILD respectively adopting this one, considering they are providing a package over very none standard ways to the Arch Linux community (downloading via a *foreign* site) and not through the official repo or the AUR. However there was little to no progress so far.

Latest Comments

« First ‹ Previous 1 .. 33 34 35 36 37 38 39 40 41 42 43 .. 91 Next › Last »

juanignaciosl commented on 2022-08-18 11:36 (UTC)

@noctiluus: no solution for the black menu o far. @a172: how can I "have a screen at position 0,0"? I'm sorry, I don't know what that means. I thought that it might be related to the relative positions of my two displays, but I haven't found any arrangement that makes it works.

a172 commented on 2022-08-16 02:08 (UTC)

@daffydack - Make sure xwayland is installed. Even when running zoom natively in wayland, it is necessary for it to start up. I've seen this behavior in electron apps as well.

@juanignaciosl and @noctiluus - unfortunately, wonky menus are fairly common for qt applications (zoom is one) in wayland. A work around for them showing up in the wrong place is to make sure you have a screen at position 0,0. For the menu showing up, but the contents not being drawn, I have had luck with resizing the parent window, holding the mouse still for a few seconds over the button that opens the menu, and/or moving the mouse off of the menu and back on it. Some fiddling with those usually brings it up. It is very annoying, and just when I think I've figured out the correct incantation to make it work, it changes. Very annoying.

noctiluus commented on 2022-08-10 13:37 (UTC) (edited on 2022-08-10 13:53 (UTC) by noctiluus)

@juanignaciosl Do you know if there is a solution to the black menu error? I have that as well. From what I can tell, the menu is still operable, merely invisible. As when I scroll over it, it will populate a popup window. I've installed the upstream version, and it appears to have the same graphical error, as well.

edh commented on 2022-08-10 03:04 (UTC)

@kriansa Thanks for the link, I will degrade ibus to an optional dependency with the next release.

@dmedinag I believe gst-plugin-pipewire is only an indirect dependency and not strictly required by zoom itself. Please correct me if I am wrong about this!

kriansa commented on 2022-08-09 23:01 (UTC)

@edh: According to this thread, ibus is only required for remote control. Would you be willing to turn ibus into a optional dependency?

dmedinag commented on 2022-08-06 20:46 (UTC)

Screenshare did not work for me (Gnome-wayland) until I installed gstreamer's plugin for pipewire.

Installing gst-plugin-pipewire fixed the issue. Should this be added as a dependency?

« First ‹ Previous 1 .. 33 34 35 36 37 38 39 40 41 42 43 .. 91 Next › Last »