Combines 2 PRs, to get Wayland share working#188
Combines 2 PRs, to get Wayland share working#188dac73 wants to merge 6 commits intoflathub:masterfrom
Conversation
|
Started test build 21486 |
|
Build 21486 successful |
|
Started test build 21497 |
|
Build 21497 successful |
|
Started test build 21498 |
|
Build 21498 successful |
|
Tested the install, looks fine. |
|
Started test build 21500 |
|
Build 21500 successful |
|
I tried I'm using gnome / wayland on Fedora 32. |
|
@kaj can you check which permissions does zoom have after install? Thanks. |
|
@dac73 , according to gnome settings, it seems to have full access to /dev and network as built-in unchangeable permessions, and notifications and running in background are enabled as integration (sorry about the wording, my gnome is in Swedish, so the english words here are just my attempts at translation). But I'm not really sure the above is about the testing version, it might be remains from the "official" flatpak version (which I had installed earlier but uninstalled for this experiment). When installing the flatpak, it said: |
|
Sounds about right. For me it worked when I manually added permissions |
|
Lots of output in terminal when I start zoom: Then the following line when I enter a room: And no more output when I click share screen, but the selector window only contains the Whiteboard. (and all this is after running the |
|
We need more people testing this, it worked for me on F32:Gnome:Wayland :man_shrugging: |
|
I have been testing this build in fedora 32. One odd issue I am facing is not all windows are shared in screen sharing. |
|
I tried to access the build with flatpak install but it says 404 |
|
bot, build |
|
Queued test build for us.zoom.Zoom. |
|
Started test build 22134 |
|
Build 22134 successful |
|
right. |
|
same bot, build |
|
Queued test build for us.zoom.Zoom. |
|
Started test build 25560 |
|
Build 26339 successful |
|
@dac73 in case it's useful: I just tried this out, looks like I just get a blank screen. Fedora Silverblue 32, updated today. Tried this with your suggested overrides as well, same result. |
|
Zoom seems to now request the screenshot to be saved in |
|
Try setting |
|
The directory is very much hardcoded on zoom's side |
|
Hmm could you then symlink /tmp/zoom to be the mentioned path on Zoom start? |
|
Should I open an MR for that? |
|
You could symlink it, but I don't believe it is going to achieve anything meaningful, unless we are able to intercept dbus commands and change the path gnome uses to save the screenshot. I'm not sure if there is such a feature in flatpak? I would imagine some kind of path remapping to the overlayfs. But I feel like it's a bit of a niche to exist yet. |
Did this include sharing individual windows? |
|
@kamalmarhubi nope, only per screen. |
|
bot, build |
|
Queued test build for us.zoom.Zoom. |
|
Started test build 29830 |
|
Build 29830 successful |
|
Is there any intent on landing this? We're most likely going to need to make incremental progress towards the goal and having heaps of open MR's with different contents isn't really helpful. |
|
Adding |
|
Is there anything this pull request breaks? If not, I agree with nanonyme, it should be merged. |
|
Actually, I just tried this branch and have multiple issues with it. First, for some reason my screen share shows x11 windows. I think Zoom launches under XWayland but not sure why... I then purged all zoom config files from my home directory and reinstalled the flatpak. Now I get the following error. which seems to be caused by this line in the us.zoom.Zoom.json file. |
From what I understand, Zoom is compiled without Wayland support. They are probably the only ones who can fix that. #24 |
Actually that seems to have changed? Setting Sadly, screen share still does not seem to work for me, it either captures a black screen or crashes. I think something on the Zoom side has changed again... |
|
@kaimast Thanks for sharing that. I was able to launch Zoom as a native Wayland app (based on the changed window decorations and the xeyes trick). I can start a new meeting, select "Share Screen", and it presents me with the option to share my entire desktop, or a whiteboard. This is exactly the same behaviour as when I launch it under XWayland. Under XWayland, sharing the desktop "works", partially (the windows that appear to others are the ones also running under XWayland). Under Wayland, other users see nothing. On the other hand, under native Wayland, Zoom crashes if I try to join anyone else's meeting (it plays <1 second of the audio stream, loads none of the video elements, then exits). I can't find any useful logs or errors to help work this out at the moment, so back to XWayland for now. |
Strange. Regular meetings work fine for me. There are a few glitches with HighDPI and mouse input, but otherwise everything is fine. I wonder if they are still using gnome's screenshot API for wayland screenshare or something else like pipewire. Looking at the licenses, it seems the have switched from Qt5.6 to Qt5.12, so a bunch of stuff might have changed. |
That's normal. |
|
I'm not too sure why this MR is still open. I've already submitted MRs to get most of the stuff working: If screen sharing doesn't work in the latest version, then that's just Zoom changing stuff again. I'd like to suggest to submit MRs since the repo always has room for improvement, for example this one. @kparal in my experience, I've had issues with Zoom in a Wayland back-end; it would crash for a couple of times when I would join a meeting, which is a big issue in my opinion. I'd like to suggest enabling Wayland manually. |
I meant it only shows those windows running under XWayland. I cannot actually share any content of wayland clients. There is still a crash involving screen recording on wayland so I am not sure if I want to create a merge request for my branch just yet... |
|
I created a new pull request at #255. Let's close this one? |
|
This is stale, closing. |

Combines #182, #143, adds update if conf already exists (need to test).
Closes #18, #22