xdg-desktop-portal-wlr: Unable to share screen on Arch with Chromium
I’m unable to share screen on Arch using chromium 88.0.4324.182-1, am only getting a black screen. I’ve also tried with firefox 85.0.2-1 but doesn’t work either.
The chrome flag #enable-webrtc-pipewire-capturer is enabled.
export XDG_CURRENT_DESKTOP=sway is set before executing sway.
XDG_SESSION_TYPE is set to wayland
exec "systemctl --user import-environment" is at the end of the sway config file.
Installed dependencies and their versions:
xdg-desktop-portal 1.8.0-1
xdg-desktop-portal-wlr 0.1.0-5
xdg-desktop-portal-wlr 0.2.0-1
libpipewire02 0.2.7-1
pipewire 1:0.3.22-1
The test script yields:
python3 xdp-screen-cast.py
Traceback (most recent call last):
File "/home/user/dev/test/19/xdp-screen-cast.py", line 113, in <module>
screen_cast_call(portal.CreateSession, on_create_session_response,
File "/home/user/dev/test/19/xdp-screen-cast.py", line 55, in screen_cast_call
method(*(args + (options, )),
File "/usr/lib/python3.9/site-packages/dbus/proxies.py", line 72, in __call__
return self._proxy_method(*args, **keywords)
File "/usr/lib/python3.9/site-packages/dbus/proxies.py", line 141, in __call__
return self._connection.call_blocking(self._named_service,
File "/usr/lib/python3.9/site-packages/dbus/connection.py", line 652, in call_blocking
reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.ScreenCast” on object at path /org/freedesktop/portal/desktop
I’m happy to provide further information if needed, please just let me know what would be needed to troubleshoot this issue.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 43 (1 by maintainers)
I don’t know if you got it working by now but you might wanna look into this thread: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/768 After uncommenting
metadatain/etc/pipewire/media-session.d/media-session.confit worked on my system again.The fix for https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/768 is included in pipewire 0.3.23.
@itaranto
A segfault is a very serious issue. #52 is likely the segfault you are seeing (and that issue remains open). It happens when our connection to pipewire fails. It is an easy fix, but it has been low priority as it only happens when we are already exiting with an error. If fixed today, you would still be having your issue.
/usr/bin/pipewire-media-sessionis not this project so we don’t keep issues open for their segfaults. That’s why this was labeled “upstream bug”, " invalid", and closed. It is also likely a duplicate of #88, but the root cause of that issue was never conclusively determined.Regardless, I’m always happy to help users debug their problems in closed issues.
Thanks for the clarification, I’ll keep an eye on that PR.
This is actually not true. The screen being shared is currently somewhat arbitrary. It is whichever display the wayland protocol informs us of first when we retrieve a list of displays in the xdpw code.
#59 seeks to implement a graphical chooser, so each new screensharing session will ask you which display you want to share through a mechanism of your choosing.
Chromium result: after installing
libpipewire02and setting the internal Chromium flag related to Pipewire (as mentioned in the FAQ), screensharing works in the same way as Firefox, but unfortunately Chromium can longer see Electron windows like Slack.That did it! Note to others that it only shares the display that Firefox starts the share on, so manage your windows accordingly. If you move Firefox to a different display, the share will continue on the original display (i.e. the share doesn’t follow Firefox). I’ll test Chromium later.
The default firefox package on Arch probably doesn’t have reliable support yet (but I can’t say for sure, I haven’t had it installed for a while).The firefox-nightly package (in the AUR) is working (as of 87.0a1.20210203-1). You can also install fedora-firefox-wayland-bin from the AUR. I’ve used that successfully for some time.Edit: The firefox in Arch extra seems to be working fine. I can’t say why you’re having trouble with it. I have version firefox-86.0-2 installed. Someone updated the wiki and it seems it has been working since version 84. You mention that it gives you no options of windows to select. It may be confusing as you need to select the option that reads “Use Operating System settings”. I should also note that individual window sharing is not supported yet, but whole screen sharing is.
You are likely missing a chrome flag. WebRTC pipewire support is not enabled by default. If you look here, under Chromium for Arch, you’ll see a note reading
Chromium is always able to see other Chromium/Electron windows and tabs. It’s a thing they’ve added support for in some fashion entirely independent of the compositor.
Good to know!
I know, I was mentioning that both services crashed. Now that I found out about this pipewire bug, it makes sense to be labeled like that, it’s just I didn’t saw that kind of explanation. Thanks.
Yes, you’re right. Uncommenting the
metadatafield from/etc/pipewire/media-session.d/media-session.conffixes the pipewire segfault and also the screen sharing issue. Thanks!I had to reboot my machine after changing the config file though…
For the curious, the segfault in pipewire was because of this.
So, the fix should arrive in the next pipewire release.
@itaranto Sound like this issue: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/768
@pbartyik Glad you got it working and sorry that you’re having so much trouble with other services not starting automatically.
I’ve found the folks over at https://gitlab.freedesktop.org/pipewire to be very helpful if you want to follow up on pipewire not starting.
Thanks all for the helping hand. @Flyxi121 your solution of starting everything manually works. No idea why systemd isn’t starting xdg-desktop-portal and pipewire automatically, but that’s a problem for another day.
Edit: For clarification, I ran
pipewireand/usr/lib/xdg-desktop-portal -v -rmanually. xdpw did not need manual start.Hmm I’m on artix so I don’t have systemd. But the procedure for starting pipewire and then using xdg-desktop-portal-wlr on my system is:
pipewire/usr/lib/xdg-desktop-portal -r & /usr/lib/xdg-desktop-portal-wlr -o DP-3(DP-3 is the monitor)If you installed xdg-desktop-portal-wlr from the AUR the executable will be in
/usr/lib/. Note that the-rflag is used to replace the old instance of xdg-desktop-portal and xdg-desktop-portal-wlr can’t be running or there will be an error. So for testing just usekill xdg-desktop-porand it should work. There is no message to stdout when pipewire started correctly on my system so maybe that could cause some confusion. Let me know if that helped!edit: I thought I might share the output of xdp and xdpw:
/usr/lib/xdg-desktop-portal -v -r:/usr/lib/xdg-desktop-portal-wlr -l DEBUG -o DP-3:When I start screensharing I get the following messages.
/usr/lib/xdg-desktop-portal -v/usr/lib/xdg-desktop-portal-wlr -l DEBUG -o DP-3pipewireThank you all for your input! I’ll be able to test tomorrow morning (in about 10 hours), and I’ll update this post with results.
Update:
I tried to uncomment
metadatain/etc/pipewire/media-sessions.d/media-sessions.confwhich didn’t help. I don’t have a~/.config/pi*folder, so can’t really delete it.I also tried the
-gitpackages forpipewireandxdg-desktop-portal-wlrwhich didn’t help either.I’m not nearly familiar enough with how this solution needs to work to be able to troubleshoot this effectively: what would be the way of verifying that the moving parts are actually talking to each other and passing what needs to be passed?
Edit: This xdpw install is my first attempt to screen share on sway, historically there may have been dependencies that other users still have installed but no longer listed as dependencies?
Edit2: I’m unable to click allow in firefox as well.
I also ran into this issue after a recent update on Archlinux. I tried uncommenting metadata, checked all the configurations etc. but nothing helped. In the end, I “fixed” the issue by deleting the
~/.config/pipewire-media-sessiondirectory. The directory has not been re-created since, so I dunno why it even existed in the first place. Not sure if this is what fixed it in the end, but now things are working again. Might be some combination of several things mentioned in this thread. Hope this helps someone.Let’s stick with Chrome for now and see if we can get it working there. You said that the flag was enabled, so no other changes should be required.
You’re gonna have to start xdpw from a terminal so that we can force it to quit and produce a core dump.
Go to the mozilla gum test page and click capture screen. When the dialog pops up, let me know if you can see your output displayed. If you can’t, there is still a selectable button there, but it is completely blank (white) because there is no preview to show. That’s okay, the preview is the same thing as the full sized sharing session as far as xdpw is concerned.
Before doing anything else, wiggle the cursor around on the display being shared. Sometimes it won’t send a first frame until something on the shared display changes.
If it still won’t show you anything in the preview window, go to the terminal where xdpw is running and hit
Ctrl-\. This will force it to quit and produce a core dump.You can run
coredumpctl debugto start gdb on the most recent coredump. Whatever folder you happen to be in is where the log will be written.Then you can run the following commands from inside gdb.
Then you can paste that log here and we’ll take a look at where xdpw was stuck.