Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
I want to run a script on start and stop of my Sunshine session which switches the display to a dummy HDMI port, changes resolution and refresh rate, and so on. The reason I pretty much have to do that is that my primary monitor is pretty much incompatible with the resolutions and refresh rates of my clients, and I only had limited success editing the EDID of the monitor to add those. (Also, my monitor has features that effectively hot-swap its EDID, and these stop working correctly if I override the EDID on the kernel command line to a fixed one.)
This works well, mostly. The big issue I still regularly have is that the persistent portal token seems to be bound to my primary display. So when I say "Allow" and "persist" in the screen sharing dialog that pops up, I really only allow and persist for my primary display. When sunshine switches to the HDMI display, a new dialog pops up on the fake invisible screen to allow capture, and obviously I cannot allow the capture via sunshine, a real chicken and egg problem.
If I'm near the machine, I can press "enter" and hope that this will properly accept on the dialog that I cannot see. If I'm not near the machine, I'm pretty much out of luck. I've had some success with "transplanting" tokens in the permission DB, but it's very brittle.
Is there any solution I didn't think of? Is it maybe possible to blanket allow sunshine for all present and future displays? (Permission-wise, if I grant it access to my primary display, that's pretty much already the highest level of trust.) Not sure this can be solves in Sunshine itself, but I bet I'm not the only person in that situation. Switching to "fake" displays is popular.
Expected Behavior
No response
Additional Context
No response
Host Operating System
Linux
Operating System Version
cachyOS rolling updates
Architecture
amd64/x86_64
Package
Linux - LizardByte/pacman-repo
GPU Type
NVIDIA
GPU Model
GeForce RTX 5090
GPU Driver/Mesa Version
latest 595
Capture Method
XDG Portal Grab (FreeBSD/Linux)
Apps
Log output
While the dialog is being displayed, sunshine hangs uninterruptibly on:
[2026-07-10 16:48:58.604]: Info: [portalgrab] Loaded portal restore token from disk
Online logs
No response
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
I want to run a script on start and stop of my Sunshine session which switches the display to a dummy HDMI port, changes resolution and refresh rate, and so on. The reason I pretty much have to do that is that my primary monitor is pretty much incompatible with the resolutions and refresh rates of my clients, and I only had limited success editing the EDID of the monitor to add those. (Also, my monitor has features that effectively hot-swap its EDID, and these stop working correctly if I override the EDID on the kernel command line to a fixed one.)
This works well, mostly. The big issue I still regularly have is that the persistent portal token seems to be bound to my primary display. So when I say "Allow" and "persist" in the screen sharing dialog that pops up, I really only allow and persist for my primary display. When sunshine switches to the HDMI display, a new dialog pops up on the fake invisible screen to allow capture, and obviously I cannot allow the capture via sunshine, a real chicken and egg problem.
If I'm near the machine, I can press "enter" and hope that this will properly accept on the dialog that I cannot see. If I'm not near the machine, I'm pretty much out of luck. I've had some success with "transplanting" tokens in the permission DB, but it's very brittle.
Is there any solution I didn't think of? Is it maybe possible to blanket allow sunshine for all present and future displays? (Permission-wise, if I grant it access to my primary display, that's pretty much already the highest level of trust.) Not sure this can be solves in Sunshine itself, but I bet I'm not the only person in that situation. Switching to "fake" displays is popular.
Expected Behavior
No response
Additional Context
No response
Host Operating System
Linux
Operating System Version
cachyOS rolling updates
Architecture
amd64/x86_64
Package
Linux - LizardByte/pacman-repo
GPU Type
NVIDIA
GPU Model
GeForce RTX 5090
GPU Driver/Mesa Version
latest 595
Capture Method
XDG Portal Grab (FreeBSD/Linux)
Apps
Log output
Online logs
No response