Closed Bug 1430775 Opened 7 years ago Closed 4 years ago

[Wayland] Screensharing doesn't work the screen stays black

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Product:
Core
Component:
WebRTC: Audio/Video
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1672944
Tracking Flags:
Tracking Status
firefox59 --- affected

People

(Reporter: rhubscher, Assigned: jhorak)

References

(Blocks 1 open bug)

Details

When using appear.in screen sharing capability with Firefox and Wayland the shared screen stays black.
Component: General → WebRTC
OS: Unspecified → Linux
Rank: 25
Component: WebRTC → WebRTC: Audio/Video
Priority: -- → P3
I guess that means having pipewire support at least?
PipeWire is solved at Bug 1496359. You can check Fedora or flatpak packages (https://firefox-flatpak.mojefedora.cz/) which have the PipeWire patches from Bug 1496359.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE

(In reply to Martin Stránský [:stransky] from comment #2)

PipeWire is solved at Bug 1496359.
You can check Fedora or flatpak packages
(https://firefox-flatpak.mojefedora.cz/) which have the PipeWire patches
from Bug 1496359.

I use wayland on an uptodate archlinux installation. I installed pipewire and xdg-desktop-portal{,-gtk}.
firefox 67.0.2

The python script provided in the following links works (so my pipewire installation works)

python3 gnome-screen-cast.py

But I still experience the problem. I can't share my screen (it's black but I can see my cursor).
https://mozilla.github.io/webrtc-landing/gum_test.html

I tried with an empty profile, with firefox nightly (flatpak), with or without GDK_BACKEND=wayland → same problem.

Nevertheless it's seems to work on Fedora :
https://jgrulich.cz/2018/07/04/how-to-enable-and-use-screen-sharing-on-wayland/
I think it's due to this patch (just a guess from the filename):
https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-pipewire.patch

So for what I know : this bug isn't resolved on unpatched firefox.

Nevermind, I didn't saw "RESOLVED FIXED in Firefox 68".
Maybe firefox-nightly failed due to flatpak… I will wait for firefox 68 to reopen this bug if it's still there.

I just test with firefox 68 developer-edition … and the problem is still there.

Assignee: nobody → jhorak

The problem is that the pipewire support is currently disabled during build. I'll look into it.

Dan: could you please help me out there? I'm trying to set the rtc_use_pipewire dynamically by adding --with-pipewire mozconfig option:
https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/webrtc.gni#74
How can I do that with the gn->moz.build conversion tools?

Flags: needinfo?(dminor)

(In reply to Jan Horak [:jhorak] from comment #7)

Dan: could you please help me out there? I'm trying to set the rtc_use_pipewire dynamically by adding --with-pipewire mozconfig option:
https://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/webrtc.gni#74
How can I do that with the gn->moz.build conversion tools?

Hi Jan,

It is possible to set gn variables from mozconfig in this file: [1]. But you would still have to generate moz.build files using the process described here: [2]. To be able to do this dynamically we would have to run gn directly during the build rather than generating moz.build files. We have Bug 1534615 on file to do this. Our main concern about switching to running gn directly during the build is making things even more difficult for downstream maintainers. It would be helpful if you could comment on that bug if you have any opinions on this.

Chris worked on the moz.build generation, he might be able to help out here.

Dan

[1] https://searchfox.org/mozilla-central/source/build/gn.mozbuild
[2] https://firefox-source-docs.mozilla.org/build/buildsystem/gn.html

Flags: needinfo?(dminor) → needinfo?(cmanchester)

I'm sorry, Dan is right, this isn't supported by the current conversion scheme. One idea might be to see if we can unconditionally enable but rely on defines to turn on/off the relevant code, but I'm not sure if that's feasible.

Flags: needinfo?(cmanchester)

I'm still looking into it, enabling pipewire and moz.build regen with steps from above adds a few source files to compile and some libs too. I doubt I can enable pipewire conditionally without manually changing the generated moz.build file which is I guess is not allowed.

Can we re-open either this bug or 1496359?

Flags: needinfo?(jhorak)

I think it makes sense to reopen this one, since bug 1496359 already has landed patches.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

(In reply to Dan Minor [:dminor] from comment #12)

I think it makes sense to reopen this one, since bug 1496359 already has landed patches.

Thanks Dan.

Flags: needinfo?(jhorak)

I think this is related - but when I'm prompted to share my screen by the browser, the options include "Entire Screen" which is completely black. I can still share individual windows, but it seems that only non-Wayland windows are shown (Electron apps, Qt apps).

(If you think this is unrelated, I'm happy to redirect this to a new bug)

Yup, this is the bug that might cause that behavior. What compositor are you using? Gnome? KDE? Sway? You may need to install xdg-desktop-portal for your compositor as well, but a patched Firefox is currently also necessary because of this issue. Fedora has implemented such a patch.

I'm on Gnome 3.34.4, and I already have xdg-desktop-portal installed.

I'm using Manjaro/Arch, so I'll see what I can do to get the patch from Fedora working on my setup. Thank you for pointing me in the right direction!

There's a package in the AUR called fedora-firefox-wayland-bin that is precompiled with the patch. When you installed xdg-desktop-portal, you should have chosen to also install xdg-desktop-portal-gtk for Gnome to work.

Not sure if this patch isn't ready yet, or some other component in the environment isn't working:

I've added Fedora's patch to AUR/firefox-wayland-hg.
pipewire and xdg-desktop-portal are running as I can see them through systemctl --user status. (But I ended up stopping them and running by hand where I can keep a look).
I started xdg-desktop-portal-wlr by hand.
set XDG_CURRENT_DESKTOP=sway.
I can see a screen if I start xdg-screen-cast.py.
Ran firefox and started screen sharing in Hangouts.
When allowing permission there are two options: a blank line, and "Entire Screen".
Nothing happens afterward. No error in debug's console or the terminal in which I ran firefox. Dropping sharing permission shows a failure message, but I believe that's expected.

If I start firefox but first set GTK_USE_PORTAL=1, than xdg-desktop-portal immediately crashes (SIGSEGV) with:

(/usr/lib/xdg-desktop-portal:252823): GLib-GIO-CRITICAL **: 14:06:50.914: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed

@pedro.laracampos Are you using a wlroots based compositor? Who are you quoting there? If you're struggling with xdg-desktop-portal-wlr, I'd be happy to help you out over on #sway on freenode, because we're a little off topic on this issue. Or feel free to raise an issue over at xdg-desktop-portal-wlr on github. Fair warning, it is in an alpha state, but it does work. I've yet to build and try firefox-wayland-hg.

The quotes were an accident I was listing my steps with '>'.
Yes I'm using sway (a wlroots based compositor), and I'm quite sure it's working for basic screen sharing. What I'm not sure is what in the combo { firefox-hg + xdg-portal + pipewire.patch + portal-wlr } is not.
But yeah, this is probably very portal-wlr specific, so I'm heading to #sway.

Screen sharing still doesn't work on Wayland (of native Wayland windows/display) as of Firefox 76 (from Flathub on GNOME 3.36)...
What is holding this up?

Read the issue?

I did... if I understand correctly this is a build-system related issue?
Anything we (people not familiar with it) can do to help out?

Sadly no. Upstream Firefox can't support custom built flags for gn built third party libraries. Unless you want to become intimately familiar with the build system, you likely can't fix this issue for everyone.

You'll see a lot of distros patching their Firefox builds, notably Fedora. We are slowly putting together a compatibility table here: https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility It is very incomplete.

You can also compile Firefox yourself and apply the appropriate patches, but then you're building your own browser with each new release.

Is firefox going to update its webrtc code for the new pipewire-0.3? I tried applying the Fedora pipewire patch, but even with some modifications I was unable to build it against the new pipewire version because of some missing headers and type declarations.

It isn't a question of whether or not Firefox will update or not. The WebRTC codebase is developed independently (check out webrtc.org). A patch has already been written for pipewire 0.3 for OpenSuse Tumbleweed. Their patchay serve you better.

This isn't really an issue though, because pipewire 0.3 daemon is backwards compatible with 0.2 consumers. You just need to have the 0.2 libraries installed, which don't conflict name wise. Arch provides a libpipewire02 package that does exactly that, while allowing all of pipewire 0.3 to be installed at the same time. I believe Void Linux has also started packaging the 0.2 libraries independently.

You just need to have the 0.2 libraries installed, which don't conflict name wise.

Not really possible on my system, because headers come in the same package as the daemon itself.

What distro do you use? Could you package the libs yourself?

Also, I forgot, the pipewire 0.3 patch was for OpenSuse Tumbleweed's Chromium package, but like I said, the pipewire codebase is shared, so it should be easy to port this to FF.

https://build.opensuse.org/package/view_file/openSUSE:Factory/chromium/build-with-pipewire-0.3.patch?expand=1

What distro do you use?

Gentoo

Could you package the libs yourself?

I think, I could, but it's not the way it's usually done on Gentoo. libpipewire is a shared librarary?

the pipewire 0.3 patch was for OpenSuse Tumbleweed's Chromium package, but like I said, the pipewire codebase is shared, so it should be easy to port this to FF.

Thanks. I think, I'll try this.

Could you package the libs yourself?

I think, I could, but it's not the way it's usually done on Gentoo. libpipewire is a shared librarary?

They are shared libraries, yes.

Hello,

What's the status of this bug?

I see that Fedora is including this patch: https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-pipewire-0-3.patch

Shouldn't that patch be included upstream?

GNOME is now defaulting to wayland in a lot of distributions (Debian,...) and not being able to share the desktop is a problem

(In reply to Dan Shick from comment #24)

Sadly no. Upstream Firefox can't support custom built flags for gn built third party libraries. Unless you want to become intimately familiar with the build system, you likely can't fix this issue for everyone.

Has a bug report been posted for this issue/limitation with gn builds? I'd like to see how the issue is being addressed. Thank you.

(In reply to ian-s-mcb from comment #33)

Has a bug report been posted for this issue/limitation with gn builds? I'd like to see how the issue is being addressed. Thank you.

Bug 1534615

If I understand correctly, there are exceedingly few cases where this issue has an impact, this being one. This issue will sort of "go away naturally" when the Wayland/Pipewire codepaths in WebRTC are stable enough that the need for build flags is removed.

I've been tracking distro packages and their patch status here https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility#webrtc-aka-firefoxchromium

Thank you, Dan. That clears up the bug situation for me.

(In reply to ian-s-mcb from comment #33)

(In reply to Dan Shick from comment #24)

Sadly no. Upstream Firefox can't support custom built flags for gn built third party libraries. Unless you want to become intimately familiar with the build system, you likely can't fix this issue for everyone.

Has a bug report been posted for this issue/limitation with gn builds? I'd like to see how the issue is being addressed. Thank you.

When Bug 1654407 is fixed, we'll no longer be code generating build files from gn, which will make it much easier to support custom build flags.

What about the other non-buildsystem related changes in the Fedora patch?

Out of the box PipeWire support is tracked at Bug 1672944.

(In reply to Martin Stránský [:stransky] from comment #38)

Out of the box PipeWire support is tracked at Bug 1672944.

Thanks, Martin. I'll follow that bug.

Let's close it as a dupe of Bug 1672944. Jan is not going to work on that any more, I'll take care of it.

Status: REOPENED → RESOLVED
Closed: 6 years ago → 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.