Screen sharing inconsistencies with different portal backends on Niri

[pietrobondioli]

Screen sharing inconsistencies with different portal backends on niri

Summary

I've been experiencing inconsistent screen sharing behavior on niri with different applications. After systematic testing of both xdg-desktop-portal-wlr and xdg-desktop-portal-gnome, I found that different portal backends have opposite failure modes with the same applications, particularly affecting Google Meet and other WebRTC-based apps.

This appears related to issue #2254, but I've collected comprehensive test data that might help narrow down the root cause.

Environment

• OS: NixOS
• niri version: 25.08
• Display resolution: 3840x2160@60Hz (scaled to 1.60)
• PipeWire version: 1.4.9
• WirePlumber: Active
• xdg-desktop-portal: 1.20.3
• Tested portal backends:
  • xdg-desktop-portal-wlr 0.8.0
  • xdg-desktop-portal-gnome 49.0

What I Tested

I created a systematic testing protocol and tested 5 different screen sharing applications with both portal backends:

1. OBS Studio
2. Vesktop (Discord client)
3. Google Meet (Zen browser)
4. teams-for-linux

Each test included monitoring 3 log streams: xdg-desktop-portal, portal backend (-wlr or -gnome), and pipewire.

Key Findings

🔥 Critical: Google Meet has opposite behavior between portals

With xdg-desktop-portal-gnome:

• ❌ Completely broken
• PipeWire format negotiation fails
• Error: pw.link: negotiating -> error (no more input formats)
• Portal picker appears but sharing never starts

With xdg-desktop-portal-wlr:

• ✅ Works perfectly... but ONLY ONCE
• ❌ Subsequent attempts fail with session state bug
• Portal picker doesn't appear after first use
• Workaround: systemctl --user restart xdg-desktop-portal-wlr
• Error: Failed to close session implementation: Unknown object '/org/freedesktop/portal/desktop/session/...'

Application Compatibility Summary

Application	wlr Portal	gnome Portal
OBS Studio	✅ Works (with errors)	✅ Works perfectly
Vesktop	✅ Works (no errors!)	✅ Works (minor warnings)
Google Meet	⚠️ Works once (session bug)	❌ Broken (PipeWire error)
teams-for-linux	❌ App bug	❌ App bug

Error Patterns

xdg-desktop-portal-wlr specific:

Realtime error: Could not get pidns for pid XXXXX: pidns required but no pidfd provided
A backend call failed: No such device or address
Failed to close session implementation: GDBus.Error:org.freedesktop.DBus.Error.UnknownObject

xdg-desktop-portal-gnome specific:

Failed to associate portal window with parent window (cosmetic - doesn't break functionality)
pw.context: params Spa:Enum:ParamId:EnumFormat: Invalid argument (no more input formats)
pw.link: negotiating -> error (no more input formats)

Documentation

I've created comprehensive test documentation that I can provide:

1. Testing Protocol screenshare-testing-protocol.md screenshare-testing-checklist.md

   • Step-by-step testing procedure
   • Exact commands used
   • Log collection methodology

2. Scenario A Results test-results-scenario-a-wlr.md

   • Complete results with xdg-desktop-portal-wlr
   • All errors and logs captured

3. Scenario B Results test-results-scenario-b-gnome.md

   • Complete results with xdg-desktop-portal-gnome
   • All errors and logs captured

4. Comparison Report screenshare-comparison-report.md

   • Side-by-side comparison
   • Error pattern analysis
   • Recommendations

Questions

1. Is the Google Meet PipeWire format negotiation issue a known problem with gnome portal + niri? The error suggests the portal and PipeWire can't agree on a compatible format.

2. Should wlr portal work with niri, or is gnome the only officially supported backend? The niri wiki suggests gnome, but wlr actually solves the Google Meet PipeWire issue (despite introducing the session bug).

3. Are there any PipeWire configuration options that might help with format negotiation for the gnome portal case?

Reproducibility

For Google Meet + gnome portal PipeWire error:

1. Configure niri with xdg-desktop-portal-gnome
2. Open Google Meet in any browser
3. Try to share screen
4. Portal picker appears and allows selection
5. "Starting presentation..." hangs forever
6. Check logs: journalctl --user -u pipewire -f shows format negotiation errors

For Google Meet + wlr portal session bug:

1. Configure niri with xdg-desktop-portal-wlr
2. Open Google Meet in browser
3. Share screen - works perfectly
4. Close browser
5. Open browser again and try to share
6. Portal picker never appears, share button stuck in "waiting" state
7. Restart portal: systemctl --user restart xdg-desktop-portal-wlr
8. Works again (once)

Willing to Help

I'm happy to:

• Provide any additional logs or debugging information
• Test patches or configuration changes
• Help develop a fix (though I'd need some guidance as I'm not deeply familiar with portal/PipeWire internals)
• Run git bisect if there's a suspected regression

This is affecting my daily workflow, so I'm very motivated to help resolve it! Let me know what additional information would be useful.

Related Issues

• Cannot use screen sharing in feishu #2254 - Support for screensharing on Firefox doesn't work (appears related to the WebRTC/browser compatibility issues I'm seeing)

[pietrobondioli]

Note on Testing Methodology

Transparency: The testing protocol and documentation were created with AI assistance (Claude Code), but all tests were performed manually by me on real hardware. The testing steps were designed through human-AI collaboration to ensure systematic and reproducible results. All errors, logs, and behaviors described are actual observations from my system.

The AI helped me:

• Structure a systematic testing approach
• Document results in an organized way
• Analyze error patterns across scenarios

I personally:

• Executed every test manually
• Verified all behaviors and errors
• Made the decisions on what to test and how to approach the problem

I'm sharing this for transparency - the data and observations are real and reproducible, even though the documentation was AI-assisted.

[skoove]

this issue is overally long, and is really just annoying to read, and none of the links work

if you are going to get AI to write everything, and tell you what to do, the least you could do is proofread and make sure the links work...

[ficd0]

I think there's a difference between AI-assisted and just... AI. The phrase "human-AI collaboration" is an immediate red flag. AI is a tool, not something you collaborate with. If you feel like you're "collaborating", you're not doing nearly enough work as the human. Word-vomit issues like this waste Yalter's valuable time.

[Sempyos]

Gnome is the portal we support using for screencasting. Others have gotten the wlr portal to work but we do not support using it.

From my usage of all of those apps, I'm able to have them work perfectly fine on Arch.

You should not use the Microsoft Teams app for Linux as it isn't developed and Microsoft has transitioned to working on the PWA instead for Linux.

Please don't use AI for issues and summarizing, it doesn't help anyone and makes this extremely hard to read, understand, and work on.

TL;DR: Im decently sure your environment is misconfigured, and that you shouldn't really report wlr portal issues here

It would probably be better to change this into a discussion post instead

[pietrobondioli]

this issue is overally long, and is really just annoying to read, and none of the links work

if you are going to get AI to write everything, and tell you what to do, the least you could do is proofread and make sure the links work...

I'm sorry, I thought the repo was already public... Just changed the visibility.

[pietrobondioli]

Gnome is the portal we support using for screencasting. Others have gotten the wlr portal to work but we do not support using it.

From my usage of all of those apps, I'm able to have them work perfectly fine on Arch.

You should not use the Microsoft Teams app for Linux as it isn't developed and Microsoft has transitioned to working on the PWA instead for Linux.

Please don't use AI for issues and summarizing, it doesn't help anyone and makes this extremely hard to read, understand, and work on.

TL;DR: Im decently sure your environment is misconfigured, and that you shouldn't really report wlr portal issues here

It would probably be better to change this into a discussion post instead

Fair enough,, I'll close the issue and spend more time investigating what's missing on my environment. Thanks!

[zhaob1n]

Hi, in my issue #2254 , I found for Feishu, gnome portal doesn't work and wlr portal works once just like the Google Meet mentioned by @pietrobondioli in this issue.

So this doesn't seems to be caused by misconfigured environment. I think it worth looking into.

I agree with the discussion about AI part but let's solve the problem.

[palesz]

niri 26.04 datapoint: gnome backend works with Chromium, and force-pipewire-invalid-modifier fixes Chromium's dmabuf import under GPU compositing

Two observations that may be useful here.

Environment: niri 26.04, NixOS 26.05, single AMD GPU (Ryzen 5 PRO 4650U / Renoir iGPU, radeonsi), Mesa 26.1.1, PipeWire 1.6.5, Brave 1.90.124 (Chromium-based) on native Wayland ozone, tested against Microsoft Teams + the webrtc.github.io getDisplayMedia sample.

1. The gnome backend's WebRTC failure mode reported here appears fixed on 26.04. With ScreenCast=gnome pinned in portals.conf, Chromium screen sharing works including window selection and the stop/reshare case (which used to fail). Presumably the 26.04 change that delays starting the cast stream until the dynamic target is selected (instead of the 1x1 placeholder stream) is what fixed it.

2. With Chromium GPU compositing enabled, screencast frames fail to import unless debug { force-pipewire-invalid-modifier } is set. Without it, Chromium's EGL import of niri's screencast dmabufs fails (eglCreateImage -> EGL_BAD_MATCH, the Camera effects crashes webcam on Wayland ozone platform if GPU compositing is ON brave/brave-browser#47596 family) and the captured stream never transmits, with both wlr and gnome backends, so it's about the buffers, not the portal. With the invalid-modifier option, the same capture works under full GPU compositing. This suggests niri advertises explicit DRM modifiers (radeonsi tiling formats?) that Chromium's EGL_EXT_image_dma_buf_import path can't import on this stack, while modifier-less negotiation imports fine.

Not sure whether the right fix is on niri's side (modifier list filtering / test-allocation against consumers) or purely Chromium's (Firefox renegotiates to MemFd on import failure, Chromium doesn't), but since a one-line niri debug option turns a 100%-broken Chromium screencast into a working one, it seemed worth documenting here. Happy to test patches or provide logs.

[Sempyos]

Would be worth trying this PR
#1791