Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Screensharing not working #22

Closed
5n00p4eg opened this issue Jan 4, 2019 · 274 comments
Closed

Screensharing not working #22

5n00p4eg opened this issue Jan 4, 2019 · 274 comments

Comments

@5n00p4eg
Copy link

5n00p4eg commented Jan 4, 2019

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
Copy link
Member

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
Copy link

matthiasclasen commented Jan 4, 2019

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

@nanonyme
Copy link
Contributor

nanonyme commented Jan 4, 2019

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

@matthiasclasen
Copy link

matthiasclasen commented Jan 4, 2019

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
Copy link
Contributor

nanonyme commented Jan 4, 2019

Do you imply a new feature in Flatpak itself?

@nanonyme
Copy link
Contributor

nanonyme commented Jan 4, 2019

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

@matthiasclasen
Copy link

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
Copy link
Contributor

nanonyme commented Jan 4, 2019

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
Copy link
Contributor

nanonyme commented Jan 4, 2019

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

@nanonyme
Copy link
Contributor

nanonyme commented Jan 4, 2019

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

@nanonyme
Copy link
Contributor

nanonyme commented Jan 4, 2019

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
Copy link

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

@nanonyme
Copy link
Contributor

nanonyme commented Jan 4, 2019

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link
Author

5n00p4eg commented Jan 8, 2019

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

I gave them a link to this issue.

@nanonyme
Copy link
Contributor

nanonyme commented Jan 8, 2019

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
Copy link

dac73 commented Mar 7, 2019

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
Copy link
Contributor

nanonyme commented Mar 7, 2019

@nanonyme
Copy link
Contributor

nanonyme commented Mar 7, 2019

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

@dac73
Copy link

dac73 commented Mar 12, 2019

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

@nanonyme
Copy link
Contributor

@barthalion said above that it doesn't

@dac73
Copy link

dac73 commented Mar 13, 2019

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
Copy link

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
Copy link
Member

@5n00p4eg Has the support answered?

@5n00p4eg
Copy link
Author

@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
Copy link
Author

Maybe we need more tickets to their bug tracker ? )

@philbates35
Copy link

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
Copy link

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
Copy link

1player commented Jun 13, 2022

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
Copy link

bdaase commented Jun 22, 2022

And there we have the PR: #337

@rmader
Copy link

rmader commented Jun 22, 2022

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
Copy link

vchernin commented Jun 22, 2022

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
Copy link

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:
image

@carlocastoldi
Copy link

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

@rmnscnce
Copy link

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

@rmnscnce
Copy link

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

@patriziobruno
Copy link
Contributor

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
Copy link

ndobbs commented Jun 22, 2022

Working great for me on Fedora 36 on Gnome 42.

@ZanderBrown
Copy link

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

@ozdreamern
Copy link

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
Copy link

rmader commented Jun 22, 2022

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
Copy link

kaimast commented Jun 22, 2022

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
Copy link

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
Copy link

rmnscnce commented Jun 22, 2022

@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):
image

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
Copy link

ozdreamern commented Jun 22, 2022

@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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

freefd commented Jun 29, 2022

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):

image
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
Copy link

rmnscnce commented Jun 29, 2022

@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
Copy link

rmader commented Jun 29, 2022

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
Copy link

freefd commented Jun 29, 2022

@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
Copy link

smlx commented Jul 1, 2022

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

@jokeyrhyme
Copy link

jokeyrhyme commented Jul 1, 2022

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
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.