Arch package depends on xdg-desktop-portal-gnome which silently breaks screencasting out of the box

[cetin-m]

Description

The niri Arch Linux package declares xdg-desktop-portal-gnome as a dependency. When both xdg-desktop-portal-gnome and xdg-desktop-portal-wlr are installed without a portals.conf, the gnome portal wins the D-Bus arbitration and xdg-desktop-portal-wlr is never activated — breaking all screen sharing silently out of the box.

This means a fresh Arch install of niri ships in a broken screencasting state with no warning, caused by niri's own dependency pulling in the conflicting portal backend.

Steps to Reproduce

1. Install niri on Arch Linux (pulls in xdg-desktop-portal-gnome as a dependency)
2. Install xdg-desktop-portal-wlr (as recommended in the wiki for screencasting)
3. Try to share screen in any browser-based app (Teams, Meet, etc.) or OBS
4. Only the browser window appears — no native picker, no other windows/outputs

Verify the problem:

systemctl --user status xdg-desktop-portal-wlr
# Shows: inactive (dead)

Root Cause

xdg-desktop-portal-gnome is listed as a required dependency of the niri Arch package. When both portal backends are installed without an explicit portals.conf, gnome takes precedence. Since xdg-desktop-portal-gnome does not speak the wlr-screencopy protocol that Niri implements, screen capture fails.

Workaround

Create ~/.config/xdg-desktop-portal/portals.conf:

[preferred]
default=wlr
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

Then restart the portal stack:

systemctl --user restart xdg-desktop-portal xdg-desktop-portal-wlr

Suggested Fix

Either:

Option A — Ship a default niri-portals.conf (or instruct users to create portals.conf) as part of the Arch package or the wiki setup guide, explicitly routing ScreenCast to wlr.

Option B — Replace the xdg-desktop-portal-gnome dependency with xdg-desktop-portal-wlr in the Arch package, since -wlr is the correct backend for Niri.

Notes

• This issue has manifested repeatedly: see Screencast doesn't work #3700 (closed 2026-03-30), Screencasting does not work by default, requires restarting desktop portals everytime. #2399, File picker won't show up on selected applications: a dbus issue? #702 — all caused by the same underlying packaging problem
• Affected users consistently report it as "screencasting broken on fresh Arch install" and have to manually discover the portals.conf fix
• xdg-desktop-portal-gnome is pulled in transitively by niri itself (pacman -Qi xdg-desktop-portal-gnome | grep "Required By" → niri)

System Information

• niri version: niri 25.x (Arch Linux)
• Distro: Arch Linux
• Affected backends: xdg-desktop-portal-wlr (inactive when -gnome is also present without portals.conf)

[HigherOrderLogic]

Default niri-portals.conf use Gnome portal as screencast backend.

Also you dont need wlr-screencopy protocol to use screencasting.

[HigherOrderLogic]

2. Install xdg-desktop-portal-wlr (as recommended in the wiki for screencasting)

This is just false.

https://niri-wm.github.io/niri/Screencasting.html

In order to use it, you need a working D-Bus session, pipewire, xdg-desktop-portal-gnome, and running niri as a session (i.e. through niri-session or from a display manager). On widely used distros this should all "just work".

Alternatively, you can use tools that rely on the wlr-screencopy protocol, which niri also supports.

Use better clanker next time.

[cetin-m]

Thank you for the correction - I had the root cause wrong on two counts.

I wasn't aware niri ships its own niri-portals.conf routing screencasting to the gnome portal, so the gnome dependency being there is clearly intentional, not a packaging mistake. And I incorrectly assumed wlr-screencopy was the required screencasting path.

One question, if you don't mind: if gnome portal is the correct and pre-configured backend, do you know what would cause screencasting to fail on a standard Arch+niri install (only the browser tab showing in the picker, xdg-desktop-portal-wlr inactive)? I want to understand whether the real problem was something else entirely (e.g. missing Chromium flags like WebRTCPipeWireCapturer/--ozone-platform=wayland), before deciding whether to close this or refile with the correct framing.

[cetin-m]

Got it, I should have read the wiki more carefully before filing this. The issue was based on incorrect assumptions. Closing.

[Sempyos]

Thank you for the correction - I had the root cause wrong on two counts.

I wasn't aware niri ships its own niri-portals.conf routing screencasting to the gnome portal, so the gnome dependency being there is clearly intentional, not a packaging mistake. And I incorrectly assumed wlr-screencopy was the required screencasting path.

One question, if you don't mind: if gnome portal is the correct and pre-configured backend, do you know what would cause screencasting to fail on a standard Arch+niri install (only the browser tab showing in the picker, xdg-desktop-portal-wlr inactive)? I want to understand whether the real problem was something else entirely (e.g. missing Chromium flags like WebRTCPipeWireCapturer/--ozone-platform=wayland), before deciding whether to close this or refile with the correct framing.

How are you starting niri..?