fix(linux/xdgportal): Properly support multiple screens by exposing pipewire streams as separate displays

[Kishi85]

Description

This PR adds proper multi-monitor support to Sunshine's XDG portal grab by exposing all streams of a capture portal as separate screens (utilizing the multiple capture mode of the screencast portal) with necessary fixes to make things work.

Things this PR does:

• Improve logging done by portalgrab.cpp for easier debugging (could be moved to a separate PR if desired)
• Properly implement XDG stop event based on DBus signal (as doing it based on matching the display resolution will break display switching)
• Remove the (already more or less defunct) session caching.
• Add missing error handling to pipewire code to prevent obvious segfaults
• Fix the (currently broken) keyboard shortcut for the switch_display_event
• Change screencast source selection mode to multiple
• Expose separate displays for each screen stream provided by the screencast portal (ordering streams consistently by screen position) - Note: This is still dependent on the Portal implementation providing streams for each selected source. I've only tested with KDE6.6 in a combined Remotedesktop+Screencast session and it's working fully there.

Known issues:

• Can segfault when trying to switch displays really quickly (by mashing the screen switch shortcut multiple times within a second) and even then it's not fully reproducible. This would have been happening even before this PR when just having a single stream but was masked due to the shortcut handling not being properly implemented in the capture logic (missing return on !push_captured_image_cb). This is a separate issue concerning other capturemethods as well (tested with KMS), see Coredump with SIGSEGV when switching displays #4943

Screenshot

Issues Fixed or Closed

• Fixes XDG portalgrab with multiple displays squishes all into one stream #4914

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[Kishi85]

@psyke83 Sorry to ping you here but can you think of a reason why the keyboard shortcut to switch displays would not work with portalgrab?

I've been trying to do so after enumerating them properly for display_names (current state of this PR) but the switch_display_event from video.cpp does not seem to be firing or handled when using portalgrab and I can't figure what I'm missing.

[psyke83]

@psyke83 Sorry to ping you here but can you think of a reason why the keyboard shortcut to switch displays would not work with portalgrab?

I've been trying to do so after enumerating them properly for display_names (current state of this PR) but the switch_display_event from video.cpp does not seem to be firing or handled when using portalgrab and I can't figure what I'm missing.

If you add some debug to video.cpp you'll see that your current code is hitting the switch_display_event->peek() case when the combination is first pressed, but the peek event then repeatedly triggers. The artificial reinit is not completing successfully for some reason.

[psyke83]

Look:

Sunshine/src/platform/linux/kmsgrab.cpp

Lines 1221 to 1230 in b172a98

	case platf::capture_e::timeout:
	if (!push_captured_image_cb(std::move(img_out), false)) {
	return platf::capture_e::ok;
	}
	break;
	case platf::capture_e::ok:
	if (!push_captured_image_cb(std::move(img_out), true)) {
	return platf::capture_e::ok;
	}
	break;

It seems that portalgrab is not checking the push_captured_image_cb callback the same way in the capture loop. The same logic may need to be added. I will look at this further later when I have time, if you don't figure it out.

[Kishi85]

Look:

Sunshine/src/platform/linux/kmsgrab.cpp

Lines 1221 to 1230 in b172a98

	case platf::capture_e::timeout:
	if (!push_captured_image_cb(std::move(img_out), false)) {
	return platf::capture_e::ok;
	}
	break;
	case platf::capture_e::ok:
	if (!push_captured_image_cb(std::move(img_out), true)) {
	return platf::capture_e::ok;
	}
	break;

It seems that portalgrab is not checking the push_captured_image_cb callback the same way in the capture loop. The same logic may need to be added. I will look at this further later when I have time, if you don't figure it out.

That is exactly what was missing to get the keyboard shortcut to work. Thanks!

[Kishi85]

I've got the basic functionality working now and can switch multiple displays using keyboard shortcuts.

The main issue right now is when the same display currently actively streaming is requested to be switched to again (e.g. currently streaming display 0 and trying to switch to it via shortcut) then the stream will disconnect due to https://github.com/Kishi85/Sunshine/blob/6d7942e0c82aeedfca16b77735f0fc6cf716a4ec/src/platform/linux/portalgrab.cpp#L1294-L1309

which is causing the stream to disconnect with Warning: PipeWire stream stopped by user. in the logs.

Problem here is that this is necessary to detect if the user stopped the stream via the XDG notification (according to @psyke83 notes in #4914 (comment)).

Possible solutions that need more research:

• Have the check detect if it is currently handling a switch_display_event. I've already had to extend it by adding the current stream position values to the mix so we can discern switching different screens without disconnecting.

• Figure out another way to detect the user disconnecting the portal manually and change that part of the stream logic.

• Update video.cpp to not reinit if switching to the same display currently active and just keep streaming (might have side-effects I can't assess).

[Kishi85]

The main issue right now is when the same display currently actively streaming is requested to be switched to again (e.g. currently streaming display 0 and trying to switch to it via shortcut) then the stream will disconnect due to https://github.com/Kishi85/Sunshine/blob/6d7942e0c82aeedfca16b77735f0fc6cf716a4ec/src/platform/linux/portalgrab.cpp#L1294-L1309

Changing the check to also include currently active switch_display_events directly works (not sure if this is the best way to do it):

auto switch_display_event = mail::man->event<int>(mail::switch_display);
if (previous_width.load() == width && previous_height.load() == height && previous_pos_x.load() == pos_x && previous_pos_y.load() == pos_y && switch_display_event->peek()) {

Next issue is when changing displays via shortcut too quickly there seems to be a possible race condition which can happen that freezes Sunshine hard until it is restarted and then it is exiting with: Fatal: 10 seconds passed, yet Sunshine's still running: Forcing shutdown or Fatal: Hang detected! Session failed to terminate in 10 seconds. when the session is closed on the client-side.

[Kishi85]

The main issue right now is when the same display currently actively streaming is requested to be switched to again (e.g. currently streaming display 0 and trying to switch to it via shortcut) then the stream will disconnect due to https://github.com/Kishi85/Sunshine/blob/6d7942e0c82aeedfca16b77735f0fc6cf716a4ec/src/platform/linux/portalgrab.cpp#L1294-L1309

Changing the check to also include currently active switch_display_events directly works (not sure if this is the best way to do it):

auto switch_display_event = mail::man->event<int>(mail::switch_display);
if (previous_width.load() == width && previous_height.load() == height && previous_pos_x.load() == pos_x && previous_pos_y.load() == pos_y && switch_display_event->peek()) {

Scratch that solution as I've had a typo (missing inversion) there and didn't realize that the event is already popped when the display gets reset by video.cpp and the portal re-initialzies. Back to square one on that.

Next issue is when changing displays via shortcut too quickly there seems to be a possible race condition which can happen that freezes Sunshine hard until it is restarted and then it is exiting with: Fatal: 10 seconds passed, yet Sunshine's still running: Forcing shutdown or Fatal: Hang detected! Session failed to terminate in 10 seconds. when the session is closed on the client-side.

Sunshine hanging when switching too quickly is still an issue.

UPDATE: This could be related to chosen encoder, having tried vulkan and vaapi yields different results (hang vs. SEGV).
After running with a debugger I'm seeing the SEGV in https://github.com/FFmpeg/FFmpeg/blob/15504610b0dc12c56e5e9f94ff06c873382368f5/libavcodec/hw_base_encode.c#L508 related to ctx being invalid/missing. Could we have an issue with switching from one pipewire_stream to another upon calling portal_t->init() multiple times? Simply adding a lock mutex for the whole init function does not seem to do the trick. It's likely somewhere in the capture or encoder logic.

UPDATE 2: More or less consistently reproducible when switching screens back and forth without waiting for the stream to update to the new screen. Does not seem to trigger if waiting for the stream to update to the new screen after switching plus a second or two more.

[psyke83]

The crashing (whether hang or segfault) may be due to the pipewire loop still being active during fake reinit.

See this block here:

Sunshine/src/platform/linux/portalgrab.cpp

Lines 1363 to 1370 in b172a98

	if (stream_stopped.load()) {
	BOOST_LOG(warning) << "PipeWire stream stopped by user."sv;
	capture_running.store(false);
	stream_stopped.store(false);
	previous_height.store(0);
	previous_width.store(0);
	pipewire.frame_cv().notify_all();
	return platf::capture_e::error;

And here:

Sunshine/src/platform/linux/portalgrab.cpp

Lines 1393 to 1399 in b172a98

	case platf::capture_e::interrupted:
	capture_running.store(false);
	stream_stopped.store(false);
	previous_height.store(0);
	previous_width.store(0);
	pipewire.frame_cv().notify_all();
	return status;

You may also need to set these same variables when you intend to signal an artificial reinit (i.e., when push_captured_image_cb returns false) to ensure the encoder fully stops.

Regarding the race condition that causes a hang, one of the changes in #4875 resolves a hang after disconnect that happens when there are no screen updates happening. Since the on_process callback doesn't fire, the capture loop gets stuck. I worked around that by checking the pull_free_image_cb result during timeout, so you may want to see if you need to do a similar check elsewhere (or perhaps find a better fix).

[Kishi85]

I'll stop force-pushing most things im doing right now and will be squashing the whole thing in the end after we've got all the kinks ironed out. A few things I've done and learned now:

• 9146245 Adds a prefix to all log messages from portalgrab.cpp so messages can be easily identified in the log (could do that as a separate PR as well if desired)
• Added a lot more logging on what goes on with pipewire_t and the session cache. Things learned from that:
  • When video.cpp switches displays it calls reset_display() which in term resets the shared_ptr to the current display implicitly destroying pipewire_t and then reinitialzing a new display from scratch.
  • pipewire_t::cleanup_stream() always invalidates the session cache. Since it is called by the destructor of pipewire_t the session cache is never actually used? (c432cb6 fixes this without any noticable changes in behaviour)
• 20af084 Temporarily disables the session ending logic via XDG notification icon
  • If you try to access an ended session pipewire returns a specific error Pipewire Error, id:2 seq:8 message: no target node available (causing a green screen on the connected client) that could be used to better track a user ending the session via the xdg notification.

With all these changes I seemingly have managed to get a stable reproducer for the crash (SEGV) by switching to the same display that is currently streaming. This is working on a single monitor setup as well, allowed by the implementation in video.cpp and should just fully reset the display (+pipewire stream) without segfaulting. The crash only occurs when switching to the same display. Switching to another display and then back to the first one does not seem to crash (as easily) unless you're switching very quickly but that might just be resulting in a switch to the same display internally in the end.

I'm wondering if this is related to the whole session caching (which is currently more or less defunct on master anyway) and will try to remove the whole session cache to see what happens when this is using a fresh portal every time a new display is constructed. video.cpp already ensures that only one capture is active (due to other capture methods limitations) so multiple XDG notifications should never be an issue in the first place Without session cache the client is just getting a greenscreen.

UPDATE: Testing this again and again leads to the same result: Segfault is only happening when trying to switch to the same screen that is already streaming even though the display reset/initialization looks the same in the log as when switching from one screen to another. It is properly reusing the session cache now and connecting to the same pipewire_node for each display. Could this be some quirk when repeatedly streaming the same node from pipewire? Switching to a different node and then back to the first one does not seem to trigger this issue.

[Kishi85]

After a lot of trial and error I've managed to cut the hangs when switching display down to only when very quickly, repeatedly switching (to the same? haven't tried others) display. You have to basically mash the shortcut to get a segfault. My theory for that is that when switching really quickly something in the capture logic combined with pipewire just cannot keep up (some thread sync issue?).

This is still an issue but I'm wondering if it can be mitigated in video.cpp as it seems unreasonable to allow queuing another switch_display_event while the previous one's reset_display has not finished:

Sunshine/src/video.cpp

Lines 1478 to 1484 in b172a98

	// Process any pending display switch with the new list of displays
	if (switch_display_event->peek()) {
	display_p = std::clamp(*switch_display_event->pop(), 0, (int) display_names.size() - 1);
	}
	// reset_display() will sleep between retries
	reset_display(disp, encoder.platform_formats->dev_type, display_names[display_p], capture_ctxs.front().config);

All other issues I've had with this are basically ironed out now:

• Hanging issue for switching to the same display is (almost fully) solved.
• XDG notification stream end is implemented via the associated pipewire error and not by matching screen properties
• The session cache is now properly invalidated only when a display_name that is not in the list is requested. This can happen as display_names enumerate directly from a separate portal instance (so that is always the current state). As display_names are just position and resolution values as "x,y,w,h" portal->init matches pipewire_streams based on those. Also we do not have to invalidate the session cache for removed portals as the related streams will just stay in there unused.

Things still todo before I'm likely to remove the draft status:

• Tone down logging to debug level for most of the newly added messages.

[Kishi85]

Squashed, rebased and description+title updated. This is ready for review.

There's still one known issue (that was there before this PR just masked, see description for details) but maybe someone reviewing this has an idea on how to fix or work around that.

[psyke83]

Unfortunately the XDG stop still doesn't stop for me on KDE or GNOME. My CPU should not be excessively slow (5700X), but I tried bumping the wait time to eliminate the possibility:

diff --git a/src/platform/linux/portalgrab.cpp b/src/platform/linux/portalgrab.cpp
index b7ff3100..2076d535 100644
--- a/src/platform/linux/portalgrab.cpp
+++ b/src/platform/linux/portalgrab.cpp
@@ -1431,8 +1431,9 @@ namespace portal {
       while (true) {
         // Check if PipeWire signaled a dead stream
         if (shared_state->stream_dead.exchange(false)) {
+          BOOST_LOG(warning) << "[portalgrab]: wait for dbus";
           // Wait 100ms so the portal session closed signal can catch up if it's late. Not sure if this can be handled better...
-          std::this_thread::sleep_for(std::chrono::milliseconds(100));
+          std::this_thread::sleep_for(std::chrono::milliseconds(2000));
           // If the pipewire stream stopped due to closed portal session stop the capture with an error
           if (dbus.is_session_closed()) {
             BOOST_LOG(warning) << "[portalgrab] PipeWire stream stopped by closed portal session."sv;

Still unsuccessful:

Apr 08 22:10:04 archlinux sunshine[10402]: [2026-04-08 22:10:04.826]: Debug: [portalgrab] PipeWire stream state: streaming -> paused
Apr 08 22:10:05 archlinux sunshine[10402]: [2026-04-08 22:10:05.836]: Warning: [portalgrab]: wait for dbus
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.836]: Warning: [portalgrab] PipeWire stream disconnected. Forcing session reset.
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.856]: Debug: [portalgrab] Destroying pipewire_t
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.856]: Debug: [portalgrab] Stop PW thread loop
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.856]: Debug: [portalgrab] Cleaning up stream
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.856]: Debug: [portalgrab] Stop fill_img
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.856]: Debug: [portalgrab] Disconnect stream
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.856]: Debug: [portalgrab] PipeWire stream state: paused -> unconnected
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Destroy stream
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Disconnect PW core
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Destroy PW context
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Close pipewire_fd
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Stop PW thread loop
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Destroy PW thread loop
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.857]: Debug: [portalgrab] Unsubscribing closed session signal: 77
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.858]: Warning: [portalgrab] Failed to explicitly close portal session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/portal/desktop/session/1_128/Sunshine7”
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.858]: Info: [portalgrab] Loaded portal restore token from disk
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.858]: Debug: [portalgrab] Finalizing Portal security: dropping capabilities and resetting dumpable
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.860]: Debug: [portalgrab] RemoteDesktop CreateSession response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.860]: Debug: [portalgrab] RemoteDesktop CreateSession: got session handle: /org/freedesktop/portal/desktop/session/1_128/Sunshine8
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.866]: Debug: [portalgrab] SelectDevices response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.866]: Debug: [portalgrab] SelectSources response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.873]: Debug: [portalgrab] RemoteDesktop Start response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.876]: Debug: [portalgrab] Subscribed closed session signal: 88
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.877]: Info: [portalgrab] Found stream for display: 'DP-1' position: 0x0 resolution: 1536x864
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.877]: Debug: [portalgrab] Unsubscribing closed session signal: 88
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.877]: Debug: [portalgrab] Explicitly closed portal session: /org/freedesktop/portal/desktop/session/1_128/Sunshine8
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.877]: Debug: [portalgrab] Start PW thread loop
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.877]: Info: [portalgrab] Requested frame rate [60fps]
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.888]: Info: [portalgrab] Loaded portal restore token from disk
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.889]: Debug: [portalgrab] Finalizing Portal security: dropping capabilities and resetting dumpable
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.890]: Debug: [portalgrab] RemoteDesktop CreateSession response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.890]: Debug: [portalgrab] RemoteDesktop CreateSession: got session handle: /org/freedesktop/portal/desktop/session/1_135/Sunshine9
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.896]: Debug: [portalgrab] SelectDevices response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.897]: Debug: [portalgrab] SelectSources response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.904]: Debug: [portalgrab] RemoteDesktop Start response_code: 0
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.906]: Debug: [portalgrab] Subscribed closed session signal: 99
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.907]: Info: [portalgrab] Streaming display 'DP-1' from position: 0x0 resolution: 1536x864
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.907]: Debug: [portalgrab] Setup PW context
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.908]: Debug: [portalgrab] Connect PW context to fd
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.908]: Debug: [portalgrab] Create PW stream
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.908]: Debug: [portalgrab] Connect PW stream - fd 41 node 68
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.908]: Debug: [portalgrab] PipeWire stream state: unconnected -> connecting
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.909]: Info: [portalgrab] Connected to pipewire version 1.6.2
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.909]: Debug: [portalgrab] PipeWire stream state: connecting -> paused
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.911]: Info: [portalgrab] Video format: 12
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.911]: Info: [portalgrab] Size: 1920x1080
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.911]: Info: [portalgrab] Framerate (from compositor): 0/1 (variable rate capture)
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.911]: Info: [portalgrab] using DMA-BUF buffers
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.912]: Info: [portalgrab] Video format: 12
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.912]: Info: [portalgrab] Size: 1920x1080
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.912]: Info: [portalgrab] Framerate (from compositor): 0/1 (variable rate capture)
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.912]: Info: [portalgrab] using DMA-BUF buffers
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.912]: Debug: [portalgrab] PipeWire stream state: paused -> streaming
Apr 08 22:10:07 archlinux sunshine[10402]: [2026-04-08 22:10:07.918]: Info: [portalgrab] Using negotiated resolution 1920x1080

Same issue on GNOME:

Apr 08 22:14:05 archlinux sunshine[13437]: [2026-04-08 22:14:05.326]: Debug: [portalgrab] PipeWire stream state: streaming -> paused
Apr 08 22:14:06 archlinux sunshine[13437]: [2026-04-08 22:14:06.328]: Warning: [portalgrab]: wait for dbus
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.328]: Warning: [portalgrab] PipeWire stream disconnected. Forcing session reset.
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.348]: Debug: [portalgrab] Destroying pipewire_t
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.348]: Debug: [portalgrab] Stop PW thread loop
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.348]: Debug: [portalgrab] Cleaning up stream
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.348]: Debug: [portalgrab] Stop fill_img
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.348]: Debug: [portalgrab] Disconnect stream
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.348]: Debug: [portalgrab] PipeWire stream state: paused -> unconnected
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Destroy stream
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Disconnect PW core
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Destroy PW context
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Close pipewire_fd
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Stop PW thread loop
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Destroy PW thread loop
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Debug: [portalgrab] Unsubscribing closed session signal: 77
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Warning: [portalgrab] Failed to explicitly close portal session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/portal/desktop/session/1_116/Sunshine7”
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.349]: Info: [portalgrab] Loaded portal restore token from disk
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.350]: Debug: [portalgrab] Finalizing Portal security: dropping capabilities and resetting dumpable
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.351]: Debug: [portalgrab] RemoteDesktop CreateSession response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.351]: Debug: [portalgrab] RemoteDesktop CreateSession: got session handle: /org/freedesktop/portal/desktop/session/1_116/Sunshine8
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.357]: Debug: [portalgrab] SelectDevices response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.357]: Debug: [portalgrab] SelectSources response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.367]: Debug: [portalgrab] RemoteDesktop Start response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.368]: Debug: [portalgrab] Subscribed closed session signal: 88
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.369]: Info: [portalgrab] Found stream for display: 'DP-1' position: 0x0 resolution: 1920x1080
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.369]: Debug: [portalgrab] Unsubscribing closed session signal: 88
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.370]: Debug: [portalgrab] Explicitly closed portal session: /org/freedesktop/portal/desktop/session/1_116/Sunshine8
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.370]: Debug: [portalgrab] Start PW thread loop
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.370]: Info: [portalgrab] Requested frame rate [60fps]
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.378]: Info: [portalgrab] Loaded portal restore token from disk
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.379]: Debug: [portalgrab] Finalizing Portal security: dropping capabilities and resetting dumpable
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.381]: Debug: [portalgrab] RemoteDesktop CreateSession response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.381]: Debug: [portalgrab] RemoteDesktop CreateSession: got session handle: /org/freedesktop/portal/desktop/session/1_122/Sunshine9
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.387]: Debug: [portalgrab] SelectDevices response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.387]: Debug: [portalgrab] SelectSources response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.395]: Debug: [portalgrab] RemoteDesktop Start response_code: 0
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.396]: Debug: [portalgrab] Subscribed closed session signal: 99
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.397]: Info: [portalgrab] Streaming display 'DP-1' from position: 0x0 resolution: 1920x1080
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.397]: Debug: [portalgrab] Setup PW context
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.398]: Debug: [portalgrab] Connect PW context to fd
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.398]: Debug: [portalgrab] Create PW stream
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.398]: Debug: [portalgrab] Connect PW stream - fd 41 node 100
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.398]: Debug: [portalgrab] PipeWire stream state: unconnected -> connecting
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.398]: Info: [portalgrab] Connected to pipewire version 1.6.2
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.398]: Debug: [portalgrab] PipeWire stream state: connecting -> paused
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.401]: Info: [portalgrab] Video format: 12
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.401]: Info: [portalgrab] Size: 1920x1080
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.401]: Info: [portalgrab] Framerate (from compositor): 0/1
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.401]: Info: [portalgrab] Framerate (from compositor, max): 60/1
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.401]: Info: [portalgrab] using DMA-BUF buffers
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.402]: Info: [portalgrab] Video format: 12
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.402]: Info: [portalgrab] Size: 1920x1080
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.402]: Info: [portalgrab] Framerate (from compositor): 0/1
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.402]: Info: [portalgrab] Framerate (from compositor, max): 60/1
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.402]: Info: [portalgrab] using DMA-BUF buffers
Apr 08 22:14:08 archlinux sunshine[13437]: [2026-04-08 22:14:08.403]: Debug: [portalgrab] PipeWire stream state: paused -> streaming

I also checked to see if it's an issue related to an idle desktop not firing callbacks, but keeping 60fps content running on the desktop while clicking the XDG icon has the same result.

[Kishi85]

Unfortunately the XDG stop still doesn't stop for me on KDE or GNOME. My CPU should not be excessively slow (5700X), but I tried bumping the wait time to eliminate the possibility:
...

I also checked to see if it's an issue related to an idle desktop not firing callbacks, but keeping 60fps content running on the desktop while clicking the XDG icon has the same result.

I've changed the check to do a synchronized call (that fetches the version property of the portal.Session) and if that one fails then the portal must have closed.

Could you try with the latest version of this PR? It should work there, if it's still broken then something very weird is going on and the pipewire stream pauses/stops before the portal closed.

[psyke83]

It's working now! The previous iteration of your PR was failing on my setup due to my system_tray = disabled config seemingly interfering with the g_dbus_connection_signal_subscribe call persisting. I didn't have time to check any deeper due to your refresh; the latest changes have correct XDG stop behaviour when system_tray is enabled or disabled. I also checked resolution change and it's still working fine on GNOME and KDE.

Apologies for not specifying my config earlier; I didn't expect that the systray setting would have such an interaction with portalgrab that we were seeing here.

[Kishi85]

All good. Honestly I'd never have guessed that the system tray would have interacted with the signaling. It's still better to do it with a calling a DBus Method on the session anyway as that gives an immediate and correct result without having to worry about synchronizing states between DBus and Pipewire. Also less complexity to understand if someone else has to look at it again.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ReenigneArcher]

system_tray = disabled

FYI, I believe the original cause (crashing) for people disabling the tray was resolved in the following PRs

• test: add screenshots tray#86 (also resolved random unit test failures in the tray library)
• build(deps): bump third-party/tray from 4caf0d0 to 563dee4 #4894

I'm also moving to a new tray backend on Linux in #4907

[Kishi85]

@ReenigneArcher Since we've fixed all fixable issues @psyke83 had so far this PR it should be good to go (at least for another CI run).

Would it be possible to do the final merge without squashing the commits? or should I consider putting them into separate PRs?
I've tried to fix pre-requisite issues in separate commits (with proper semantic commit messages) so the final one can implement the feature in a working condition and I think it would be helpful (for future referencing) not to squash everything into one huge commit.

[ReenigneArcher]

Would it be possible to do the final merge without squashing the commits? or should I consider putting them into separate PRs?

Unfortunately not, the repo forces squash and merge, because the date of the commit will be used for the newly created pre-release. If we use the original commits instead of squashing then the new pre-release would end up being a lower version than the current pre-release

[Kishi85]

I see. Thanks for the explanation. Also since the squashed commit seems to reference back to this PR with the separate commits that should be sufficient anyway.