1496359 - [Wayland] We need to implement PipeWire support

Status: RESOLVED FIXED

(Core :: WebRTC, enhancement, P3)

Description

[Martin Stránský [:stransky] (ni? me)]

Desktop sharing needs PipeWire support to work under Wayland:

https://github.com/xhorak/firefox-devedition-flatpak/blob/master/org.mozilla.FirefoxNightly/firefox-pipewire.patch

Comment 1

[Paul Adenot (:padenot)]

Are the people who wrote this patch interested in upstreaming it? This mostly touches webrtc.org, it's best to make the patch there maybe? Or we can land in Firefox and then upstream from there.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

(In reply to Paul Adenot (:padenot) from comment #1)
> Are the people who wrote this patch interested in upstreaming it? This
> mostly touches webrtc.org, it's best to make the patch there maybe? Or we
> can land in Firefox and then upstream from there.

It's going to be upstreamed:
https://webrtc-review.googlesource.com/c/src/+/103504

The authors told me they wanted to upstream it first and then propagate to Firefox.

Thanks.

Comment 3

[Paul Adenot (:padenot)]

Amazing. We update our webrtc.org copy periodically, so this will start working when this patch is merge and we uplift.

Closing this for now, because we won't have to do anything in this bug, but many thanks to the people that wrote this implementation and for notifying us that it's going to work in the future!

Comment 4

[Martin Stránský [:stransky] (ni? me)]

(In reply to Paul Adenot (:padenot) from comment #3)
> Amazing. We update our webrtc.org copy periodically, so this will start
> working when this patch is merge and we uplift.
> 
> Closing this for now, because we won't have to do anything in this bug, but
> many thanks to the people that wrote this implementation and for notifying
> us that it's going to work in the future!

Can we please leave it open to block the wayland tracker until it's fixed in Firefox? I can close it when this is merged to Firefox.

Thanks.

Comment 5

[Paul Adenot (:padenot)]

Sure, at your convenience, just putting in the bits so that it does not show as "to be triaged" for us, and setting you as assignee, feel free to close when appropriate.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Paul, 
the patch is live at upstream WebRTc project now [1]. Can we have it applied to Firefox trunk?
Thanks.

[1] https://webrtc.googlesource.com/src/+/318da51f99f91e3de1192f29d7f1824958f9f13e

Comment 8

[Dan Minor [:dminor]]

I normally handle merges from upstream, so I'll assign this to myself now that it has landed upstream.

If this applies relatively cleanly, I might be able to get this in for Firefox 66, but more likely for Firefox 67 (opens January 28th). If it does not apply that cleanly, it will have to wait until the next time we do a full update from upstream.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

(In reply to Dan Minor [:dminor] from comment #8)
> I normally handle merges from upstream, so I'll assign this to myself now
> that it has landed upstream.
> 
> If this applies relatively cleanly, I might be able to get this in for
> Firefox 66, but more likely for Firefox 67 (opens January 28th). If it does
> not apply that cleanly, it will have to wait until the next time we do a
> full update from upstream.

Thanks, that's a great news. We can provide you an updated patch version for Firefox 66/67 from the original patch author - please let me know if you have any issues.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Dan, any update here? When we can expect next WebRTC merge from upstream? Or do you want rather moz-central patch? Thanks.

Comment 11

[Dan Minor [:dminor]]

Hi Martin,

I spent a day looking at this a few weeks ago. The problem is not so much the patch itself, which I was able to get to apply with minimal changes, but how we implement gn support in our build system. We rely upon running gn on each supported system and then checking in the resulting json file which is in turn used to generate moz.build files that we use to build. For platforms we don't support directly, e.g. BSD, Linux on aarch64, we rely upon maintainers for those platforms to run gn and provide us with the resulting json files. Because this patch moves files around, it will break all of the other platforms until they re-run gn. It is also triggering bugs in our moz.build code generation which is making it difficult to build and test the patch on a supported Linux build.

At this point, I think the best bet would be to wait until the next webrtc.org update (which is not scheduled, but will block Bug 818631) or until we run gn directly as part of the build, rather than checking in json files (for which I just filed Bug 1534615).

Since I don't know when either of those will happen, I'm going to leave this bug assigned to myself for now. If it looks like it is going to be a long time, I will attempt to workaround the problems I mentioned rather than letting this wait indefinitely.

Sorry about the delay!

Comment 12

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Don't set _GLIBCXX_DEBUG in webrtc.org build config; r=ng!

This define is not set in the current gn generated json and moz.build files.
If I rerun gn, this define ends up being set, and the build will fail with
a variety of link time errors.

My guess is that enable_iterator_debugging was not set when I last ran gn for
x64 Linux, and that it was subsequently enabled without regenerating the gn
files and noticing that it causes problems.

Comment 13

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Add PipeWire support to desktop capture; r=ng!

This is an import of upstream commit 318da51f99f91e3de1192f29d7f1824958f9f13e.

Depends on D27367

Comment 14

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Conflict resolutions for Pipewire support patch; r=ng!

Depends on D27368

Comment 15

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Update gn configs (part 1); r=ng!

Since the only change for non-pipewire builds is moving some files, I
regenerated the x64_True_x64_linux.json file using gn, then generated
a patch file for the other configurations. This will hopefully remove
the need for non-Tier 1 platform maintainers to re-run gn for their
platforms.

Depends on D27369

Comment 16

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Update gn configs (part 2); r=ng!

Depends on D27371

Comment 17

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Update moz.build file; r=ng!

Depends on D27372

Comment 18

[Dan Minor [:dminor]]

Attachment: Bug 1496359 - Make pipewire desktop capture support compile; r=ng!

This removes references to abseil which is not yet used by the version of
webrtc.org in tree. It also removes a duplicate definition of a kBytesPerPixel,
which is probably results from our use of unified builds.

With these changes and some hacking of moz.build files I was able to get the
pipewire support to compile but not link. I don't have an environment set up
to build and test this properly, so I didn't take it any further.

Depends on D27373

Comment 19

[Nico Grunbaum [:ng, @chew:mozilla.org]]

LGTM r+. I guess abseil is something we are going to see showing up in the next WebRTC.org update.

Comment 20

[Dan Minor [:dminor]]

Hi Martin, I've backported the patch and it is ready to land. For our builds, I've left pipewire support disabled for now. I'll land this in a day or two, I just wanted to let you know that it was coming as I was under the impression you had local patches applied to get pipewire support building on your side. Thanks!

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ceed4e0b3373
Don't set _GLIBCXX_DEBUG in webrtc.org build config; r=ng
https://hg.mozilla.org/integration/autoland/rev/3f0981f37c1c
Add PipeWire support to desktop capture; r=ng
https://hg.mozilla.org/integration/autoland/rev/f9a9da6129c0
Conflict resolutions for Pipewire support patch; r=ng
https://hg.mozilla.org/integration/autoland/rev/4485e8e0f70e
Update gn configs (part 1); r=ng
https://hg.mozilla.org/integration/autoland/rev/7ff592d37e6c
Update gn configs (part 2); r=ng
https://hg.mozilla.org/integration/autoland/rev/ae4456baac24
Update moz.build file; r=ng
https://hg.mozilla.org/integration/autoland/rev/6ca18bea93f9
Make pipewire desktop capture support compile; r=ng

Comment 22

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/ceed4e0b3373
https://hg.mozilla.org/mozilla-central/rev/3f0981f37c1c
https://hg.mozilla.org/mozilla-central/rev/f9a9da6129c0
https://hg.mozilla.org/mozilla-central/rev/4485e8e0f70e
https://hg.mozilla.org/mozilla-central/rev/7ff592d37e6c
https://hg.mozilla.org/mozilla-central/rev/ae4456baac24
https://hg.mozilla.org/mozilla-central/rev/6ca18bea93f9

Comment 23

[Martin Stránský [:stransky] (ni? me)]

Thanks a lot!

Comment 24

[Maxime de Roucy]

I use wayland on an uptodate archlinux installation. I installed pipewire and xdg-desktop-portal{,-gtk}.
Mozilla Firefox 68.0b10 (firefox-developer-edition)

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

• https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
• https://gitlab.gnome.org/snippets/39

python3 gnome-screen-cast.py

But I still experience a black video when I try screen sharing (it's black but I can see my cursor moving).

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.
(maybe there is a firefox config to change to make firefox use pipewire ?)

Comment 25

[Gunter Grodotzki]

Is there a new ticket/issue that exists for the implementation of pipewire support without manually patching so we can link it here? Else its confusing that this bug is marked as resolved when its not fully the case yet.

Comment 26

[Maxime de Roucy]

(In reply to Gunter Grodotzki from comment #25)

Is there a new ticket/issue that exists for the implementation of pipewire support without manually patching so we can link it here? Else its confusing that this bug is marked as resolved when its not fully the case yet.

Jan Horak [:jhorak] is still working on https://bugzilla.mozilla.org/show_bug.cgi?id=1430775 but that ticket/issue is also in a "RESOLVED" state.

Comment 27

[Dan Shick]

Can we re-open either this bug or 1430775?

Comment 28

[Dan Minor [:dminor]]

I've reopened Bug 1430775.

Comment 29

[Dan Shick]

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

I've reopened Bug 1430775.

Thanks