Created attachment 671386 [details] Popup when trying to share screen, text not selectable to copy-paste net-im/zoom doesn't allow to share screen on GNOME Wayland, because it has a whitelist that doesn't include Gentoo based on os-release and/or lsb-release parsing.
I have reported this upstream at: https://support.zoom.us/hc/en-us/requests/new Let's see if they're more responsive than last time.
Great, I've received an automatic reply: From: "Zoom Support (Zoom Video Communications)" <support@zoomus.zendesk.com> Subject: [Request Closed] zoom-5.4.53391.1108: Unable to share screen on GNOME Wayland To: Ulm <ulm@gentoo.org> Date: Sat, 21 Nov 2020 07:50:37 +0000 Reply-To: Zoom Video Communications <support+id8813387@zoomus.zendesk.com> [...] Unfortunately, we are unable to respond to your open tickets at this time. We encourage you to leverage our Online Resources. If you are a part of a corporate account, and need advanced technical support beyond our Online Resources, please contact your Zoom account administrators. I must admit that I am close to dropping maintainership of this package, because upstream is totally uncooperative and unresponsive. They should be glad that distros make their client available.
This sys-apps/bubblewrap solution looks pretty clever https://forums.gentoo.org/viewtopic-p-8578101.html#8578101
Me and ulm worked on a solution based on bubblewrap. The /etc/os-release he offered me didn't work out, but a stock one from an ubuntu LTS did work. I haven't had time to figure out which settings we can change there without triggering this stupid dialog, in order to have Gentoo mentioned at least in a few places still, should they look at that to find that it's maybe worth dropping this nonsense. So I did get it to work, but with the state of pipewire/gnome-shell/xdg-desktop-portal-gtk/whatever I had, screenshare did work, but it was weird. My left non-primary monitor sharing didn't work at all (other side couldn't see anything useful), and the primary monitor sharing showed just the window on it, but lacked the gnome-shell UI on top, etc. As it seemed a bit useless anyways until I looked more deeply from the pipewire angle (by now there's newer versions, etc), I didn't spend time on figuring out a good os-release file for ulm yet. I'm sure he'd appreciate help with that. To test I used the following: bwrap --dev-bind / / --ro-bind ~/ubuntu-os-release /etc/os-release /usr/bin/zoom Where ~/ubuntu-os-release was /etc/os-release fetched from a ubuntu LTS install.
Maybe I should have read the newer posts on the forum thread. Now I see ulm already requested testing help there himself ;)
(In reply to Mart Raudsepp from comment #5) > Maybe I should have read the newer posts on the forum thread. Now I see ulm > already requested testing help there himself ;) I just discovered this and will start trying this out in the upcoming calls, of which I have plenty every week. These days, I'm a single (big) monitor person these days, so multi-monitor will be out of scope, until further notice.
Created attachment 723283 [details] bin/zoom wrapper used by flatpak package flatpak uses this bin/zoom wrapper to force wayland screenshare to enabled. Perhaps if this config file is flipped manually, it would bypass the distro check, if it's still there in current versions? Can't test this with actual camera anytime soon myself, perhaps someone could take a closer look. If it gives the distro warning (with no bwrap hack in use), try to change enableWaylandShare to true in ~/.config/zoomus.conf and restart the app - does it stop complaining then and does screenshare work?
> change enableWaylandShare to true in ~/.config/zoomus.conf This is working for me. Just a side note: Screenshare of videos is laggy even though "optimize for video clip" is enabled.
So, what do we do? Add a note to README.gentoo that users should add the line enableWaylandShare=true to their ~/.config/zoomus.conf, or replace any =false line already present?
Maybe it could also be just a similar or same approach as the flatpak wrapper?
That would mean modifying a user configuration file in HOME. I believe we have a policy saying that writing to HOME is off-limits. strace shows that zoom tries to read ~/.config/zoomus.conf but also /etc/xdg/zoomus.conf. What happens if you put a file containing a single line enableWaylandShare=true in the latter location?
Until we find a better solution, I have added a hint in README.gentoo: --- a/net-im/zoom/files/README.gentoo +++ b/net-im/zoom/files/README.gentoo @@ -3,3 +3,6 @@ display compositing. If you encounter a black window when sharing the screen, then one of the following actions should help: - Enable compositing in your window manager if it is supported - Alternatively, run the xcompmgr command (from x11-misc/xcompmgr) + +To enable screen sharing on GNOME Wayland, edit ~/.config/zoomus.conf +and change the value of enableWaylandShare to true.
Please test if the problem is fixed in version 5.11.0.3540. Release notes say: "Resolved an issue regarding sharing content on Gnome 41 with Wayland"
