@juanignaciosl - In sway, you would use something like:
swaymsg output eDP-1 position 0 0
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 |
Submitter: | edh |
Maintainer: | edh |
Last Packager: | edh |
Votes: | 690 |
Popularity: | 9.24 |
First Submitted: | 2015-08-15 13:18 (UTC) |
Last Updated: | 2025-05-21 02:34 (UTC) |
« First ‹ Previous 1 .. 25 26 27 28 29 30 31 32 33 34 35 .. 83 Next › Last »
@juanignaciosl - In sway, you would use something like:
swaymsg output eDP-1 position 0 0
@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.
@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.
@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.
@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!
@edh: According to this thread, ibus
is only required for remote control. Would you be willing to turn ibus
into a optional dependency?
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:
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)