Confirming this on the same versions, with some measurements that narrow
it down.
Environment: Ubuntu 26.04, GNOME Shell 50.1, mutter 50.1,
xdg-desktop-portal 1.21.1, xdg-desktop-portal-gnome 50.0, Wayland, 4x 2560x1440.
**It is the portal itself that hangs, not just the requesting app.** While
wedged, this from an unrelated process never returns:
gdbus call --session --dest org.freedesktop.portal.Desktop \
--object-path /org/freedesktop/portal/desktop \
--method org.freedesktop.DBus.Properties.Get \
org.freedesktop.portal.ScreenCast version
**No permission dialog is involved.** My case restores silently from a
restore_token, so the "click Share, then hang" step isn't required — this is
about the session starting, not about the dialog.
**It happens on the *first* monitor change, not only when going to 2 monitors.**
Toggling one display off and on again (Settings > Displays) while a client holds
a ScreenCast session reproduces it within 1-2 cycles here. Over 4 days of normal
use I logged 7 occurrences across 60 session creations (~12%), split evenly
between sessions created after a display change and after a screen unlock.
**Timing — the portal wedges ~1s after `Start` returns:**
12:32:38 compositor closes the session (display reconfigured)
12:32:41 portal poll: OK
12:32:43 SelectSources+Start return, new session, 4 streams, no dialog
12:32:44 next poll begins -> never returns <-- wedged here
12:32:49 client's first OpenPipeWireRemote begins
12:32:51 ...times out
So `OpenPipeWireRemote` is not the trigger, it is just the first caller to
notice.
**Backtrace of the wedged xdg-desktop-portal (no dbgsym, so `??`
frames):**
Thread 1 "xdg-desktop-por":
#0 syscall ()
#1 libglib-2.0 <- lock/condvar wait
#2 ?? (portal)
#3 g_closure_invoke
#7 g_signal_emit
#10 libgio-2.0 <- GDBus message dispatch
#13 g_main_loop_run
Thread 3 "pool-8": __futex_abstimed_wait_common64 (abstime=0x0)
Thread 6 "gdbus": ppoll (healthy)
The main loop is blocked on a **glib lock/condvar inside a signal handler that
GDBus dispatched**. There is no *nested* `g_main_loop_run`, so this is not
`g_dbus_connection_call_sync` waiting on mutter — it is an in-process wait, with
a thread-pool worker parked in an untimed futex alongside it. The `gdbus` worker
thread is healthy, which is why callers hang forever instead of erroring: the
connection is fine, but nothing can be dispatched.
**Narrowing:** a client that only opens a session, requests the PipeWire fd and
closes again does *not* reproduce it (7 session rebuilds across 4 monitor
toggles, no wedge). A client that holds the session and actually consumes the
streams reproduces it in 1-2 toggles. So stream teardown during reconfiguration
looks like the relevant path.
**Reproduction:**
1. Start any screen-capture client that holds a ScreenCast session and consumes
the streams (OBS with a Screen Capture source works).
2. In Settings > Displays, switch one monitor off, Apply; switch it back on,
Apply.
3. Repeat once or twice. The client stops receiving frames, and the `gdbus`
command above hangs.
**Impact:** every portal consumer in the session blocks — file choosers,
screenshots, screen sharing — not just the capture client.
**Recovery:** `systemctl --user restart xdg-desktop-portal`. It sometimes clears
on its own after 10-15 minutes, but I have also seen it still wedged after 8.
Note the wedged process is the xdg-desktop-portal frontend rather than mutter or
xdg-desktop-portal-gnome, so this may need reassigning upstream to
flatpak/xdg-desktop-portal.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to mutter in Ubuntu.
https://bugs.launchpad.net/bugs/2162543
Title:
Mutter RemoteDesktop/ScreenCast portal hangs when transitioning to 2
active monitors
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2162543/+subscriptions
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
