protonscr

steam-jupiter-stable autostart on desktop session (non-gamescope) triggers unsuppressable screencast portal prompt

steamopen Distro Family: Arch
ValveSoftware/steam-for-linux#13333 · opened 2026-06-20 by andy10115 · updated 2026-06-20 · 0 comments · github
Aandy10115 2026-06-20 github

Your system information

  • Steam client version (build number or date): steam-jupiter-stable 1.0.0.85-10
  • Distribution (e.g. Ubuntu): CachyOS
  • Opted into Steam client beta?: [Yes/No] No
  • Have you checked for system updates?: [Yes/No] Yes
  • Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs] logs attached as tar.gz archive

logs.tar.gz

  • GPU: Nvidia/Intel/AMD: 7800x3d, 7900xtx

Summary

After steam-jupiter-stable replaced the regular steam package on a recent CachyOS Handheld Edition update, Steam now triggers a KDE screencast/screen-share portal permission prompt every time it autostarts on dropping from gamescope game mode to the regular desktop session. This happens with no Remote Play action taken, and cannot currently be suppressed.

Background

The update that introduced this:

steam-jupiter-stable-1.0.0.85-10 and steam-1.0.0.85-7 are in conflict. Remove steam?

Autostart entry that launches Steam on desktop session entry:

/etc/xdg/autostart/steam.desktop

Exec=/usr/bin/steam -silent -steamdeck

Steps to Reproduce

  1. Run steam-jupiter-stable on a KDE Plasma/Wayland desktop session (not inside gamescope)
  2. Launch via the autostart entry above, or directly: steam -silent -steamdeck
  3. A KDE system permission dialog appears asking to share the screen with Steam, with no Remote Play or broadcast action taken

What's Been Ruled Out

  • Remote Play disabled in Steam settings — prompt still occurs
  • -nopipewire flag (documented for the standard Linux client) — no effect on this build
  • steamos-manager — checked both user and root daemon logs (journalctl --user -u steamos-manager, sudo journalctl -u steamos-manager) at time of prompt; no screencast/portal activity logged
  • Stale Steam process — confirmed via ps aux no lingering instance was interfering; tested clean launches after pkill -9 steam

Additional Detail: Possible Portal-Side Bug

xdg-desktop-portal-kde 6.7.0 logs marshalling errors at the time screencast is requested/denied:

QDBusMarshaller: cannot add a null QDBusVariant
QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid QVariant passed in arguments
Namespace "org.kde.kdeglobals.General" is not supported

The portal's permission store screencast table remains empty even after repeatedly denying the prompt:

$ busctl --user call org.freedesktop.impl.portal.PermissionStore /org/freedesktop/impl/portal/PermissionStore org.freedesktop.impl.portal.PermissionStore List s screencast
as 0

This suggests denials aren't being persisted — possibly a separate portal-side bug — but the practical effect is there's currently no way to permanently dismiss the prompt through normal KDE permission management. The Plasma 6.5+ Application Permissions panel is also non-functional/greyed out on this system, likely for the same underlying reason.

Expected Behavior

Steam should not request screencast capture on a normal desktop-mode autostart without an active Remote Play/broadcast session, and/or -nopipewire should suppress this on Jupiter-flavored builds the same way it does on the standard Linux client.

Nothing extracted yet.