[Wayland] We need to implement PipeWire support

RESOLVED FIXED in Firefox 68

Status

()

enhancement
P3
normal
Rank:
25
RESOLVED FIXED
9 months ago
2 days ago

People

(Reporter: stransky, Assigned: dminor)

Tracking

(Blocks 1 bug, Regressed 1 bug)

Trunk
mozilla68
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

()

Attachments

(7 attachments)

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.
Flags: needinfo?(stransky)
Reporter

Comment 2

9 months ago
(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.
Flags: needinfo?(stransky)
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!
Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → INVALID
Reporter

Comment 4

9 months ago
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Assignee: nobody → stransky
Priority: -- → P3
Reporter

Updated

9 months ago
Status: REOPENED → NEW
Reporter

Updated

9 months ago
Duplicate of this bug: 1430775
Reporter

Comment 7

6 months ago
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
Flags: needinfo?(padenot)
Assignee

Comment 8

6 months ago
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.
Assignee: stransky → dminor
Rank: 25
Flags: needinfo?(padenot)
Reporter

Comment 9

6 months ago
(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.
Reporter

Comment 10

4 months ago

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

Flags: needinfo?(dminor)
Assignee

Comment 11

4 months ago

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!

Flags: needinfo?(dminor)
Assignee

Comment 12

2 months ago

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.

Assignee

Comment 13

2 months ago

This is an import of upstream commit 318da51f99f91e3de1192f29d7f1824958f9f13e.

Depends on D27367

Assignee

Comment 15

2 months ago

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

Assignee

Comment 16

2 months ago

Depends on D27371

Assignee

Comment 17

2 months ago

Depends on D27372

Assignee

Comment 18

2 months ago

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

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

Assignee

Comment 20

2 months ago

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!

Flags: needinfo?(stransky)

Comment 21

2 months ago
Pushed by dminor@mozilla.com:
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
Reporter

Comment 23

2 months ago

Thanks a lot!

Flags: needinfo?(stransky)
Assignee

Updated

Last month
Regressions: 1545247
Regressions: 1558475

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)

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 :

I think it's due to this patch (just a guess from the filename):

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

You need to log in before you can comment on or make changes to this bug.