Symptoms & scope
- A video-call or streaming app sees no screen or produces a black screen while regular desktop windows work.
- The portal picker is missing, declines the request or returns no capture stream even though the microphone works.
Relevant environment
Wayland desktop sessions including KDE Plasma, GNOME and wlroots compositors; browsers, meetings and Flatpak applications may use XDG Desktop Portal and PipeWire.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- The selected XDG desktop portal backend may not implement the ScreenCast interface or may be mismatched to the active desktop session.
- The application, portal frontend, compositor and PipeWire stream are independent components. A denied consent prompt or missing PipeWire source does not prove a graphics driver error.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Read the reported login session type; do not assume the browser uses the same capture path.
echo "$XDG_SESSION_TYPE"Interpret the result: wayland identifies the session context, not the actual availability of a ScreenCast portal.
Check 2
Inspect the desktop identifier used when selecting portal backends.
echo "$XDG_CURRENT_DESKTOP"Interpret the result: An incorrect identifier can select a backend that does not implement the required interface.
Check 3
Read the user-session portal frontend status; backend services may have separate names.
systemctl --user status xdg-desktop-portal.serviceInterpret the result: An active frontend does not establish that the ScreenCast backend or PipeWire capture succeeded.
Evidence-guided next steps
Match the portal ScreenCast backend to the desktop session
Inspect the desktop's portal backend selection and its advertised interfaces. For KDE use the distribution's KDE portal integration, for GNOME its corresponding backend, and for wlroots an appropriate supported implementation. The portal configuration can choose a dedicated ScreenCast backend independently of the file chooser. Confirm the implementation supports the requested source type before changing anything.
Precautions: Do not indiscriminately install and activate every portal backend; competing defaults can make diagnosis harder.
Recovery / rollback: Restore the saved portal configuration and default desktop session values if a controlled change does not help.
Did this solution help you?
Distinguish user consent, PipeWire stream and application capture
Repeat the same share request with one known working portal client and record whether a source picker appears, the request is denied or a stream starts but remains black. Applications should not require global screen access merely to repair a portal-selection problem. ScreenCast uses PipeWire streams and the caller may still fail to display frames after permission succeeds.
Precautions: Screen capture is privacy-sensitive. Do not share unredacted diagnostic recordings or automatically grant persistent consent.
Recovery / rollback: Close the temporary share session, revoke its grant if needed and restore the application's previous source selection.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- XDG Desktop Portal: ScreenCast interface (project or distribution documentation)
- XDG Desktop Portal: backend selection (project or distribution documentation)
- XDG Desktop Portal: desktop integration and backends (project or distribution documentation)