Blank screen when sharing through browser.

[alanxoc3]

Hi, I haven't been able to screen share with either firefox or chromium for a while now. I have tried everything in the guide a few months ago and again today:

https://github.com/emersion/xdg-desktop-portal-wlr/wiki/%22It-doesn't-work%22-Troubleshooting-Checklist

In firefox, the screen is just blank with a mouse. Chromium doesn't even let me share the screen. OBS Studio does work however, which I find very odd.

My setup is:

• arch linux
• river 0.2.4 (wlroots)
• pipewire 0.3.71
• xdg-desktop-portal-wlr 0.7.0-1

I've tried with both wireplumber and pipewire-media-session.

This command is in the guide and outputs for me:

pw-dump | jq -r '[.[] | select(.info.props."node.name" | IN("firefox","gnome-shell","kwin_wayland","obs","xdg-desktop-portal-wlr","xdp-screencast.py")) | .id] as $pw_node_ids | [ .[] | select(.info.props."node.id" | IN($pw_node_ids[])) | .id ] as $pw_port_ids | .[] | select(.id | IN(($pw_node_ids + $pw_port_ids)[]))'

Please let me know which commands I should run to provide more information.

[J0nnyMak0]

Yes, I'm also facing a similar issue. Firefox is just completely broken as far as sharing goes. With chrome (using ozone) I'm facing the issue that when other participants share screen I only see a black screen. When I try to share, I'm unable to share, but restarting xdg-desktop-portal-wlr.service allows me to share screen. But, even after restarting the service incoming shared screen stream is blank.

[alanxoc3]

For me, restarting xdg-desktop-portal-wlr doesn't make screen sharing work. Also worth noting that I'm able to share some windows (the x-based windows I guess).

My current workaround is using obs to view the screen, then sharing the obs window from my browser.

[jalvesaq]

While configuring Sway on Ubuntu, I noted that the environment variables XDG_SESSION_DESKTOP=sway and XDG_CURRENT_DESKTOP=sway are required to get xdg-desktop-portal-wlr running automatically (and be able to share the screen through Firefox). Perhaps, only one of the two variables is required. Screen share works even though my GPU is officially unsupported.

[alanxoc3]

Thanks for the comment. I had XDG_CURRENT_DESKTOP=river before, but not the other one.

I just tried XDG_SESSION_DESKTOP=river in addition to the other one and I still have the same issue. Sharing my screen is just black with a mouse cursor when doing it through firefox/chromium.

[J0nnyMak0]

@alanxoc3 are you using vulkan by any chance?

[alanxoc3]

Looks like it:

> pacman -Qe | rg vulkan
vulkan-intel 23.1.1-1

I'm guessing that's problematic?

EDIT: I didn't have any hard dependencies on vulkan, so I tried removing it & rebooting my laptop. I still have the issue though :(

EDIT AGAIN: Actually, I have 2 more vulkan dependencies:

> pacman -Q | rg vulk     
vulkan-headers 1:1.3.248-1   
vulkan-icd-loader 1.3.245-1

Looks like wlroots depends on vulkan-icd-loader, which is probably what you're referring to.

[J0nnyMak0]

Sorry, I meant if you were using WLR_RENDERER=vulkan with sway. I've experienced instability with xdg-desktop-portal-wlr when using vulkan renderer. Doesn't sound like that is the case for you.

[alanxoc3]

Oh no. I don't have that env var set. Thanks for the suggestion though.

[sameer]

I'm also running into this. There is a "monitor" I can select to screen share, but there's nothing visible. Interestingly, the pw-dump command returns nothing.

Edit: Not sure what changed, but restarting several times with systemd made it work again...but I saw this message in the log for xdg-desktop-portal: Failed to close session implementation: Timeout was reached. Also, if you are using Slack, setting the platform to Ozone / using the wayland window decoration settings seems to break things.

[iguanajuice]

I'm pretty sure this is an issue with pipewire or something else upstream rather than with XDPW.
Running the command pacman -Si xdg-desktop-portal-wlr shows that the package for Arch Linux had been built in April, and IIRC, I remember screen capture working on both OBS and Discord at the time.

EDIT:
Nevermind. Removing xdg-desktop-portal-gnome and rebooting seems to fix the issue. Which is still weird in and of itself since I had used XDPG with XDPW for a while now without problem. What's more strange is that I was using v43 of XDPG since upgrading to v44 was causing me some issues, but now despite not upgrading XDPG it's now breaking screencasting via XDPW.

So like I said, probably an issue somewhere upstream.

[erahhal]

I don't have xdg-desktop-portal-gnome installed and yet see the same thing. On NixOS 23.05 with Sway and Wireplumber. Followed every guide and troubleshooting checklist, and pretty certain all browser settings/flags and env vars are correct. I see the connection between xdg-desktop-portal-wlr and chrome/firefox, but black screen. It works fine in OBS Studio, so XDPW/Sway/Wireplumber/Pipewire seem to be functional to a degree - something is up with the browser interactions.

[J0nnyMak0]

With firefox it seems to get into a loop like this. Maybe of some help in debugging:

00:02:28.568 [DEBUG] [wlr] [types/output/render.c:187] Disabling direct scan-out on output 'DP-1' (locks: 1)
00:02:28.568 [DEBUG] [wlr] [types/output/cursor.c:44] Disabling hardware cursors on output 'DP-1' (locks: 1)
00:02:28.573 [DEBUG] [wlr] [types/output/render.c:187] Enabling direct scan-out on output 'DP-1' (locks: 0)
00:02:28.573 [DEBUG] [wlr] [types/output/cursor.c:44] Enabling hardware cursors on output 'DP-1' (locks: 0)
00:02:28.602 [DEBUG] [wlr] [types/output/render.c:187] Disabling direct scan-out on output 'DP-1' (locks: 1)
00:02:28.602 [DEBUG] [wlr] [types/output/cursor.c:44] Disabling hardware cursors on output 'DP-1' (locks: 1)
00:02:28.606 [DEBUG] [wlr] [types/output/render.c:187] Enabling direct scan-out on output 'DP-1' (locks: 0)
00:02:28.606 [DEBUG] [wlr] [types/output/cursor.c:44] Enabling hardware cursors on output 'DP-1' (locks: 0)
00:02:28.636 [DEBUG] [wlr] [types/output/render.c:187] Disabling direct scan-out on output 'DP-1' (locks: 1)
00:02:28.636 [DEBUG] [wlr] [types/output/cursor.c:44] Disabling hardware cursors on output 'DP-1' (locks: 1)
00:02:28.640 [DEBUG] [wlr] [types/output/render.c:187] Enabling direct scan-out on output 'DP-1' (locks: 0)
00:02:28.640 [DEBUG] [wlr] [types/output/cursor.c:44] Enabling hardware cursors on output 'DP-1' (locks: 0)
00:02:28.669 [DEBUG] [wlr] [types/output/render.c:187] Disabling direct scan-out on output 'DP-1' (locks: 1)
00:02:28.669 [DEBUG] [wlr] [types/output/cursor.c:44] Disabling hardware cursors on output 'DP-1' (locks: 1)
00:02:28.673 [DEBUG] [wlr] [types/output/render.c:187] Enabling direct scan-out on output 'DP-1' (locks: 0)
00:02:28.673 [DEBUG] [wlr] [types/output/cursor.c:44] Enabling hardware cursors on output 'DP-1' (locks: 0)

[francocalvo]

@erahhal did you get anywhere? I'm currently also running i3 just because of this..

[erahhal]

@francocalvo It ended up being a bug in pipewire. With 0.3.77 I no longer had the problem.

[alanxoc3]

Updating to pipewire 0.3.77 doesn't fix the black screen sharing for me :(. Still having issues with both firefox & chrome screensharing.

[mvdan]

Worth trying the latest Firefox 117 beta - I had an issue with 116, which turned to be related to the sharing indicator window. I had a rule in sway to kill (close) those windows immediately, and apparently that stopped the screensharing and left it in a weird state. Firefox 117 doesn't use indicator windows at all, so the problem is gone - and I also got rid of the sway config rules.

[J0nnyMak0]

Worth trying the latest Firefox 117 beta - I had an issue with 116, which turned to be related to the sharing indicator window. I had a rule in sway to kill (close) those windows immediately, and apparently that stopped the screensharing and left it in a weird state. Firefox 117 doesn't use indicator windows at all, so the problem is gone - and I also got rid of the sway config rules.

oddly, it works for me in 116 where the indicator window shows up. On Nightly, there is no indicator window and Firefox apparently only shares the first 'frame' of the shared display. It does not update. It is almost as if you are sharing a screenshot of your display. I've switched back to 116 for screensharing. Hopefully, the nightly behavior won't make it into 117...

[francocalvo]

I'm testing in Firefox, Brave and Chromium, and non of those work. I can share a tab in Chromium based browsers tho.

@erahhal I'm still with the same problem. I scoured your nix config and tried to replicate some of your tweaks, but the result hasn't changed.

[erahhal]

@francocalvo Does desktop sharing in OBS work for you? If so, then it's likely an issue with pipewire or whatever is setting up connections to xdg-desktop-portal-wlr.

[francocalvo]

@francocalvo Does desktop sharing in OBS work for you? If so, then it's likely an issue with pipewire or whatever is setting up connections to xdg-desktop-portal-wlr.

It's not working with OBS using PipeWire nor XSHM.
Do you know how to check the logs for xdg-desktop-portal-wlr?

[alanxoc3]

So I had been getting around this for the past year by screen sharing an OBS window with my browser. However that stopped working 1-2 weeks ago. I tried downgrading related packages, rechecked my xdg related config, etc. I don't see any errors in the logs:

journalctl --user -u xdg-desktop-portal.service
journalctl --user -u xdg-desktop-portal-wlr.service

I'm using river, but I also tried sway with the same issue.

OBS and wl-mirror can show the screen in their windows, but chrome/firefox/qutebrowser/slack shares the screen as a blank screen and can't find the OBS window anymore.

I have no ideas for a solution at this point besides trying xorg or a re-install. Anyone have a tip?