Screensharing not working

[5n00p4eg]

Hi!
I'm using fedora 29 with wayland.

I see a message:

Can not start share, we only support wayland on GNOME with Ubuntu(17,18), Fedora(25 to 29), Debain9, openSUSE LEap 15, Arch Linux. ....

I have clean f29 setup, zoom installed as flatpack from dl.flathub.org

After removing flatpack and reinstalling from zoom.us/support/download, everything works, including google login.

Version is same: 2.6.149990.1216

[barthalion]

From strace:

708   read(22</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(23</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(23</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(23</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
731   read(9</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
731   <... read resumed> "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(25</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(21</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(24</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(32</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   <... read resumed> "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   <... read resumed> "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   <... read resumed> "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226
708   read(47</usr/lib/os-release>, "NAME=Freedesktop.org\nVERSION=\"18"..., 226) = 226

Unfortunately /usr/lib/os-release isn't writable so it can't be faked this way.

[matthiasclasen]

You could try to put an /etc/os-release. That is supposed to take precedence over /usr/lib/os-release

[nanonyme]

FD.o ships /etc/os-release already because many software directly read /etc/os-release without reading /usr/lib/os-release first.

[matthiasclasen]

Maybe there is a case for a way to override the OS identity in sandbox setup ?

We bend over backwards for proprietary software already...

[nanonyme]

Do you imply a new feature in Flatpak itself?

[nanonyme]

I guess you people already made sure there were no parameters to disable the OS detection.

[matthiasclasen]

Do you imply a new feature in Flatpak itself?

Yes, this would be an addition to flatpak override, I guess:

flatpak override --pretend-to-be="Fedora 29"

[nanonyme]

strings zoom |less

/etc/os-release
PRETTY_NAME=
VERSION_ID=
lsb_release -a
Description:
Distributor ID:
Release:
linuxmint
centos linux
centos
opensuse leap
elementary os
arch linux
hyperbola
Unknown Linux
openbox
pantheon
x-cinnamon
icewm
unity
oracle linux server
debian gnu/linux
parabola
red hat enterprise linux server
```

[nanonyme]

It actually supports quite a lot of things. Maybe they would add freedesktop.org if you asked nicely?

[nanonyme]

@matthiasclasen either that or having Flatpak be able to bind mount files from /app over files from /usr.

[nanonyme]

That would in general be useful, like you could bind mount /app/bin/foo to /usr/bin/foo where application has hardcoded the path.

[matthiasclasen]

that sounds like it has more potential to break things than just lying about the OS

[nanonyme]

Maybe. Anyhow, I dislike the override way to do this because that means Flatpak apps will not work out of the box and people keep reporting bugs. This kind of quirks would be nice to bake into the application manifest itself.

[barthalion]

Yes, I plan to contact support next week.

You could try to put an /etc/os-release. That is supposed to take precedence over /usr/lib/os-release

I think I have seen only /usr/lib/os-release in strace, file in /etc gets ignored.

[matthiasclasen]

Maybe. Anyhow, I dislike the override way to do this because that means Flatpak apps will not work out of the box and people keep reporting bugs. This kind of quirks would be nice to bake into the application manifest itself.

I only mentioned override as an example - if we add a way to to this, it would be available in finish-args as well.

[matthiasclasen]

I think I have seen only /usr/lib/os-release in strace, file in /etc gets ignored.

That would be a bug to report to them. The documentation for os-release says to look in /etc first

[5n00p4eg]

Nice to see very fast responses. Just finished ticket with Zoom.

I gave them a link to this issue.

[nanonyme]

It would be by far best conclusion if they just agreed to whitelist us imo. Preferably ignoring version since users will only ever have one runtime version with the app.

[dac73]

Even if you adjust /etc/os-release to match F29 it still doesn't work on Wayland, e.g. you can only share a whiteboard. I also added --socket=wayland override.
Recap with mocked os-release file

• zoom does start
• you can start screen share without an error message
• window/desktop picker for sharing is empty (showing just whiteboard)

[nanonyme]

Created https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/685

[nanonyme]

Note you still need to file a bug on Zoom to make it prefer /etc/os-release

[dac73]

Didn't get your last comment, Zoom is reading from /etc/os-release (check my comment)

[nanonyme]

@barthalion said above that it doesn't

[dac73]

Without mocking /etc/os-release I get a warning message about the wrong distro, with mocking /etc/os-release I get pass that message but can't pick a screen to share (this is fairly easy to test, just get into sandbox, replace /etc/os-release, which is link, with a normal file)

[philbates35]

Its been a few months now since the last comment and this is still an issue - does anyone have any idea what the situation is?

[barthalion]

@5n00p4eg Has the support answered?

[5n00p4eg]

@barthalion
Jordan Reynolds from support recommend me to use rpm version.

And about this issue:

I will send it over to our documentation team for further review, so that we do not run across this issue again.

Then my ticket was closed =(

[5n00p4eg]

Maybe we need more tickets to their bug tracker ? )

[philbates35]

Maybe we need more tickets to their bug tracker ? )

@barthalion do you think its worth creating another support ticket with them with another link to this thread and and outline of the changes we want them to make, and reasons why the way it currently is causes us issues?

I don't really understand enough about flatpaks so be able to explain why its an issue and the changes they need to make for this to be solved, so it probably makes more sense for someone else to submit a new ticket than me.

[kuba-gaj]

I have similar problem but can't even pass the popup :(
I'm on antergos and have ID_LIKE="arch" in my /etc/os-release but still getting popup saying it's not supported on my distro :(

[1player]

Engineering has informed me that the fix for this issue should be introduced in the 5.11.x version. I got this information last Thursday, but just got around to providing it to you all. My apologies for the delayed response.

It got delayed even further disappointed I'm afraid we may have to wait 4+ months

Apparently 5.11.0 should be released in a week, on June 20.

[bdaase]

And there we have the PR: #337

[rmader]

From the release notes:

Resolved an issue regarding sharing content on Gnome 41 with Wayland

If they implemented things right it should be possible to also remove these two lines from us.zoom.Zoom.json:

"--filesystem=xdg-run/pipewire-0",
"--talk-name=org.gnome.Shell",

[vchernin]

If they implemented things right it should be possible to also remove these two lines from us.zoom.Zoom.json:

"--filesystem=xdg-run/pipewire-0",
"--talk-name=org.gnome.Shell",

I can confirm screensharing works correctly on GNOME Wayland on Fedora 36 with the unnecessary permissions removed before launch.

[rmnscnce]

In reply to @rmader:

If they implemented things right it should be possible to also remove these two lines from us.zoom.Zoom.json:

"--filesystem=xdg-run/pipewire-0",
"--talk-name=org.gnome.Shell",

Looks like they're doing it right:

[carlocastoldi]

any idea when this version will be available on flathub, then? ^^

[rmnscnce]

@carlocastoldi should be available once a maintainer steps in and merges the update (with some permission tuning here and there).

[rmnscnce]

Since #337 has been merged, I suppose this issue can be closed, no?

[patriziobruno]

Since #337 has been merged, I suppose this issue can be closed, no?

I'm running the #337 test build and screen sharing works flawlessly. I agree, this can be closed.

[ndobbs]

Working great for me on Fedora 36 on Gnome 42.

[ZanderBrown]

Meanwhile, again with the #337 test build, I get segfault about 5 seconds after starting the share

[ozdreamern]

Running 5.11 (3540) in Pop_OS! 21.10 under "vanilla" Gnome Wayland (I have all pop-shell extensions disabled): when I attempt to share screen, and select "Use system capture", it loads the xdg portal popup and I am able to pick individual windows from a list (or the entire display), but no matter what I select (whole screen, individual native wayland app window, xorg/xwayland app window), but other meeting participants never see them -- it shows "[screen name] has started screen sharing" in the middle of a black background. No console errors appear (started via flatpak run -v us.zoom.Zoom). Are there any permissions I can check? I may have tweaked some in the past via Flatseal.

[rmader]

Running 5.11 (3540) in Pop_OS! 21.10

You may want to update to 22.04. Maybe you're running into a bug from the Gnome-Shell/Pipewire/driver side. Also, while debugging, you can try to disable display scaling in case you use it. Especially fractionally values such as 125% occasionally had problems in the past.

Are there any permissions I can check?

Unlikely - the portal should be all that's needed. In case they messed up you'll need --filesystem=xdg-run/pipewire-0

[kaimast]

I see the same (black screen) on Arch and Gnome42. I tried adding xdg-run/pipewire-0` to the filesystem permissions in flatseal but it didn't help.

@ozdreamern what graphics card and driver are you using? I have a Nvidia system and wonder if its another issue with their driver.

[jokeyrhyme]

Looks like screenshare works in a wlroots-based compositor (I'm using river) with the Zoom flatpak, yay

I can't figure out how to end the screen share though, the button is non-responsive

And when I tell it to quit Zoom completely as a last resort, it seems like it leaves the portal open instead of cleaning it up (I have xdp-hook rigged to show me when portal sessions are open)

The "You are screen sharing | Stop Share" floating bar successfully stays as an overlay on all workspaces when I switch

And the Stop Share button works as long as I never have any apps underneath it at any point: as soon as any other app has been underneath the Stop Share button/overlay, it's like the other app captures all hovers/clicks, even when I move the app away

[rmnscnce]

@ozdreamern you can take a look on PipeWire patchbays such as Helvum (available on Flathub) and qpwgraph to see if the display stream is actually being shared with Zoom (or any other Freedesktop.org Screencast Portal-respecting app, for that matter)

A working setup should have a connection between GNOME Shell and Zoom as seen in picture below (sorry for the mess, I can't seem to arrange slots and connections in Helvum):

You can also check whether Portal screencasting works at all by testing it with apps that are known to officially support it, e.g. OBS Studio.

[ozdreamern]

@kaimast : I have a S76 lemur pro with integrated graphics (UHD), so this is not limited to nvidia users. (Also, fractional scaling is disabled.)

@rmnscnce thanks for the tip! When I start a share, I see gnome shell "out_0" appear in Helvum, but no connection is drawn between gnome-shell and Zoom (or anything). I will test with other portal screencast apps later tonight. I also hope to upgrade to Pop 22.04 over the weekend, and will see if that helps. The pipewire version I'm currently using is 3.32. Adding back the pipewire-0 fs permission didn't help (thanks @rmader).

ETA: I tried screen/window capture via OBS Studio, and it also fails in a manner similar to Zoom, with the following log entries:

info: PipeWire initialized (sender name: 1_820)
info: User added source 'Window Capture (PipeWire)' (pipewire-window-capture-source) to scene 'Scene'
info: [pipewire] screencast session created
info: [pipewire] asking for window…
info: [pipewire] window selected, setting up screencast
info: [pipewire] server version: 0.3.32
info: [pipewire] library version: 0.3.40
info: [pipewire] header version: 0.3.40
info: [pipewire] created stream 0x55569425b380
info: [pipewire] playing stream…
error: [pipewire] Error id:2 seq:3 res:-71 (Unknown error -71): wrong resource type/version
error: [pipewire] Error id:0 seq:4 res:-2 (Unknown error -2): unknown resource 2 op:2
error: [pipewire] Error id:0 seq:5 res:-2 (Unknown error -2): unknown resource 2 op:3

I'll hope for better luck under 22.04.

[DuckDuckWhale]

It still black screens and crashes after a few seconds even after the system portal select share screen dialog showed up normally. I'm using Nvidia 510 Wayland Ubuntu 22.04.

[ozdreamern]

Following up to myself, I confirm that I was successfully able to share my screen in Zoom after upgrading to Pop!_OS 22.04 (running gnome under Wayland). Thanks to everyone who has helped foster improvements in this feature to date.

[rageagainsthepc]

I see the same (black screen) on Arch and Gnome42. I tried adding xdg-run/pipewire-0` to the filesystem permissions in flatseal but it didn't help.

@ozdreamern what graphics card and driver are you using? I have a Nvidia system and wonder if its another issue with their driver.

I would like to chip in: I'm on Fedora 36 with Gnome 42 and I also had the black screen issue. I was able to resolve the issue by switching from the proprietary nvidia driver to nouveau.

[rageagainsthepc]

Correction: It looks like switching to nouveau did not solve anything. Screensharing just worked briefly and apparently coincidentally right after I've switched display drivers. I am back to a black screen under wayland :/

[freefd]

Hi team,

Before updating to version 5.11.0.3540, I used Gnome Shell looking glass to enable unsafe context (global.context.unsafe_mode=true) and could share a screen without any issues. After updating to 5.11.0.3540, this option no longer works. Moreover, updating to the current 5.11.1.3595 did not help either, the behavior remained the same (both for DEB and Flatpak):

As you can see, there is no zoom.real in_0 as showed above. Moreover, when I click blue Share button, the system's screen sharing dialog does not appear at all.

The operation system is:

Description:	Ubuntu 22.04 LTS

~> dpkg --list | awk '/pipewire/||/zoom/{print $2" "$3}' | column -t
gstreamer1.0-pipewire:amd64            0.3.48-1ubuntu1
libpipewire-0.3-0:amd64                0.3.48-1ubuntu1
libpipewire-0.3-common                 0.3.48-1ubuntu1
libpipewire-0.3-modules:amd64          0.3.48-1ubuntu1
pipewire:amd64                         0.3.48-1ubuntu1
pipewire-audio-client-libraries:amd64  0.3.48-1ubuntu1
pipewire-bin                           0.3.48-1ubuntu1
pipewire-media-session                 0.4.1-2ubuntu1
pipewire-pulse                         0.3.48-1ubuntu1
zoom                                   5.11.1.3595

~> grep -i wayland ~/.config/zoomus.conf
enableWaylandShare=true

~> pactl info | grep Server
Server String: /run/user/1000/pulse/native
Server Protocol Version: 35
Server Name: PulseAudio (on PipeWire 0.3.48)
Server Version: 15.0.0

Can anyone provide any suggestions?

Thank you.

[rmnscnce]

@freefd does the portal service work otherwise? Try checking whether the packages relating to xdg-desktop-portals are up-to-date.

Can anyone provide any suggestions?

Test your portals functionality using ASHPD Demo and check if the "Screen Cast" one works as expected.

[rmader]

For everyone having issues: please ensure that pipewire screen sharing generally works for you. You can check e.g. by

• going to https://www.webrtc-experiment.com/RecordRTC/ and select "Fullscreen" for recording, using Firefox or Chrome (the later may need some flags to enable pipewire AFAIK)
• using OBS Studio from flathub, adding the "Screen capture (Pipewire)" source

Edit: didn't see #22 (comment) in time, sorry for the noise.

[freefd]

@freefd does the portal service work otherwise? Try checking whether the packages relating to xdg-desktop-portals are up-to-date.

Can anyone provide any suggestions?

Test your portals functionality using ASHPD Demo and check if the "Screen Cast" one works as expected.

Using ASHPD Demo I finally managed to found out some useful logs:

No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop

And I came across the comment SeaDve/Kooha#129 (comment). I then installed xdg-desktop-portal-gnome in addition to already installed xdg-desktop-portal and xdg-desktop-portal-gtk. I also added the mentioned there pipewire-media-session and libpipewire-0.3-common.

A simple reboot and screen sharing start working.

@rmnscnce thanks a lot, that was really helpful!

[smlx]

This is now fixed in the latest version of Zoom, can we close it?

[jokeyrhyme]

Yeah, I think it might be useful to close this pre-pipewire/portal ticket, and direct new post-pipewire/portal questions to a new issue?

[DuckDuckWhale]

Update: it turns out that I was affected by this Nvidia bug: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1965563
With the mentioned workaround applied, screen sharing worked (but annotations do nothing).