Command Preparations run after checking Display, making it not possible to enable a dummy HDMI just for streaming

[kinchahoy]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the nightly release?

• This issue is present in the nightly release

Describe the Bug

Command Preperations trigger only after Sunshine checks weather the \.\DISPLAY is available. This makes it impossible to trigger a change to enabled displays just for streaming.

The ideal behavior would be to only enable a dummy HDMI plug for streaming ONLY when Sunshine needs it for streaming. However, the current setup of Command Preperations does not allow for this.

Expected Behavior

Enable Command Preperations (or other scripts) to run before Sunshine checks for displays (and possibly encoders) allowing scripts to correctly prepare displays for streaming

Additional Context

No response

Host Operating System

Windows

Operating System Version

11

Architecture

64 bit

Sunshine commit or version

current

Package

Windows - installer

GPU Type

Nvidia

GPU Model

3080 TI

GPU Driver/Mesa Version

536.67

Capture Method (Linux Only)

No response

Config

hevc_mode = 0
encoder = nvenc

Apps

No response

Relevant log output

...

[mdrichardson]

I ran into this as well, for a similar use case: #1535

[Nonary]

I am confused on why this would prevent you from swapping monitors. I actually have a script I provide that does this, it doesn't even need to rely on Sunshine checking to see if the display is available or not. https://github.com/Nonary/MonitorSwapAutomation

[Nonary]

Please elaborate more on the issue, as it stands this looks like a feature request, issues are meant for submitting bug reports so just double checking.

[mdrichardson]

I am confused on why this would prevent you from swapping monitors. I actually have a script I provide that does this, it doesn't even need to rely on Sunshine checking to see if the display is available or not. https://github.com/Nonary/MonitorSwapAutomation

I only skimmed your code, but it looks like yours only switches the primary monitor? We're talking about enabling it. When disabled, it doesn't show up with dxgi-info.exe, so Sunshine doesn't think it exists and won't run the Do command.

[Nonary]

I am confused on why this would prevent you from swapping monitors. I actually have a script I provide that does this, it doesn't even need to rely on Sunshine checking to see if the display is available or not. https://github.com/Nonary/MonitorSwapAutomation

I only skimmed your code, but it looks like yours only switches the primary monitor? We're talking about enabling it. When disabled, it doesn't show up with dxgi-info.exe, so Sunshine doesn't think it exists and won't run the Do command.

That is a flaw with DXGI in general, it can only see active monitors.

But like I was saying, you can still use scripts to activate and deactivate displays. My script can activate or de-activate any display or multiple displays, it does not matter.

[mdrichardson]

I am confused on why this would prevent you from swapping monitors. I actually have a script I provide that does this, it doesn't even need to rely on Sunshine checking to see if the display is available or not. https://github.com/Nonary/MonitorSwapAutomation

I only skimmed your code, but it looks like yours only switches the primary monitor? We're talking about enabling it. When disabled, it doesn't show up with dxgi-info.exe, so Sunshine doesn't think it exists and won't run the Do command.

That is a flaw with DXGI in general, it can only see active monitors.

But like I was saying, you can still use scripts to activate and deactivate displays. My script can activate or de-activate any display or multiple displays, it does not matter.

Actually activated/enabled, or just set to primary? Like in Windows, if you go to Display Settings deactivated monitors will show grayed out. Sunshine does the monitor check prior to executing any DO commands, so your script won't even fire if the monitor is deactivated like this.

Can your MultiMonitorTool have a config that disallows the mouse or any windows to go to the monitor? That's all I'm really trying to accomplish by "deactivating" it (which I do when Sunshine isn't in use).

And I wouldn't say it's so much a flaw in DXGI or even a bug in Sunshine, more like a feature request to run the DO commands prior to the monitor/adapter check.

[Nonary]

I am confused on why this would prevent you from swapping monitors. I actually have a script I provide that does this, it doesn't even need to rely on Sunshine checking to see if the display is available or not. https://github.com/Nonary/MonitorSwapAutomation

I only skimmed your code, but it looks like yours only switches the primary monitor? We're talking about enabling it. When disabled, it doesn't show up with dxgi-info.exe, so Sunshine doesn't think it exists and won't run the Do command.

That is a flaw with DXGI in general, it can only see active monitors.
But like I was saying, you can still use scripts to activate and deactivate displays. My script can activate or de-activate any display or multiple displays, it does not matter.

Actually activated/enabled, or just set to primary? Like in Windows, if you go to Display Settings deactivated monitors will show grayed out. Sunshine does the monitor check prior to executing any DO commands, so your script won't even fire if the monitor is deactivated like this.

Can your MultiMonitorTool have a config that disallows the mouse or any windows to go to the monitor? That's all I'm really trying to accomplish by "deactivating" it (which I do when Sunshine isn't in use).

And I wouldn't say it's so much a flaw in DXGI or even a bug in Sunshine, more like a feature request to run the DO commands prior to the monitor/adapter check.

So just so we're clear here, can you explain to me what you're trying to do. If the task is, can I script a way to swap to a dummy plug prior to connecting on Sunshine, the answer is yes.

As for being active vs deactivated, yes it does that. It does not swap the primary screen, because the main goal of the script was to deactivate all screens until only one was left, which indirectly forces the remaining screen as primary. Why? Because Windows is a lot better at automatically moving windows to other screens if you do it that way.

However, there is nothing stopping you from altering the backend of the script to use something like https://sourceforge.net/projects/monitorswitcher/ instead, which would give you more flexibility such as putting monitor to sleep or whatever, instead of de-activating it.

[Nonary]

I missed the part about the mouse moving over to the other screen. Yeah my script technically disables all screens except the one you want. So you wouldn't be able to move the mouse over to the other monitors, sounds like it does exactly what you need.

[mdrichardson]

Yeah, let me clarify.

I can't speak for @kinchahoy, but I'd imagine our situations are similar. I have an UW monitor trying to stream to a 4K TV. I don't want my monitor resolution to change when streaming, so I set up a 4K virtual monitor using IddSampleDriver. I think @kinchahoy is doing the same thing via the adapter.

When I'm not streaming, I never want my mouse or windows to go to the virtual monitor. As far as I know it needs to be "disabled" in MultiMonitorTool, via the "Disable" button (I don't see one for "deactivate"). So, the DO commands have to run prior to the monitor/adapter check (unless I'm missing something)

[Nonary]

For the most part you can do anything in the do/undo command portions of Sunshine, because they are executed synchronously. So your script can take as long as it wants to do whatever it needs and you wouldn't run into a situation where you can't run a command before a stream started officially.

Since it can execute code before and after a stream, the sky is basically the limit here.

[mdrichardson]

No no no. The problem is that Sunshine does the check to see if the monitor is enabled before the DO command runs. Since it can't find the disabled monitor, the DO command never gets called. This is a feature request to have the monitor check occur after the DO command is called, which would open the flexibility to do this.

[Nonary]

No no no. The problem is that Sunshine does the check to see if the monitor is enabled before the DO command runs. Since it can't find the disabled monitor, the DO command never gets called. This is a feature request to have the monitor check occur after the DO command is called, which would open the flexibility to do this.

You don't tell sunshine to stream a specific monitor then, you just leave that empty and then use a script to set the monitors. I am doing the exact same thing you're suggesting for months now.

[FlorianWolters]

You don't tell sunshine to stream a specific monitor then, you just leave that empty and then use a script to set the monitors.

Thank you very much for this information! This was one of the missing pieces for me, to get this properly working with a virtual display (but the same would apply for a dummy physical display!).

I'm now using one "do" and one "undo" batch script. Each contains only one command interacting with the freeware MultiMonitorTool:

• "do": Deactivate physical display, activate virtual display and set resolution and refresh rate of virtual display.
• "undo": Deactivate virtual display, activate physical display and (optionally) set the host in power safe, hibernate or shutdown state (configurable via a variable).

Elevated execution of these commands in Sunshine is necessary to properly deactivate and activate the hibernate feature in Windows 11.

There is only one minor issue I got with the current solution. If the host or Sunshine crashes after "do", "undo" is not called and the host is in a state in which the only physical display is deactivated. In this case one has to interact "blind" in front of the host (or reconnect and disconnect via Moonlight after the host has been rebooted).

I've asked this question on superuser.com and asked for a fix for this annoyance, but haven't found a satisfying solution yet.

[Nonary]

You don't tell sunshine to stream a specific monitor then, you just leave that empty and then use a script to set the monitors.

Thank you very much for this information! This was one of the missing pieces for me, to get this properly working with a virtual display (but the same would apply for a dummy physical display!).

I'm now using one "do" and one "undo" batch script. Each contains only one command interacting with the freeware MultiMonitorTool:

• "do": Deactivate physical display, activate virtual display and set resolution and refresh rate of virtual display.

• "undo": Deactivate virtual display, activate physical display and (optionally) set the host in power safe, hibernate or shutdown state (configurable via a variable).

Elevated execution of these commands in Sunshine is necessary to properly deactivate and activate the hibernate feature in Windows 11.

There is only one minor issue I got with the current solution. If the host or Sunshine crashes after "do", "undo" is not called and the host is in a state in which the only physical display is deactivated. In this case one has to interact "blind" in front of the host (or reconnect and disconnect via Moonlight after the host has been rebooted).

I've asked this question on superuser.com and asked for a fix for this annoyance, but haven't found a satisfying solution yet.

There isn't an easy fix to this because the monitor can only be restored after you have signed into the computer.

Crashes and hard reboots will keep you signed out, so you'll have to set up automatic sign in on the computer as a workaround.

Then you can add a scheduled task to restore the monitors following this link Nonary/MonitorSwapAutomation#16 (comment)

To clarify, soft reboots will work without automatic sign in (like restarting from start menu) but you'll still have to do the suggestion in the link above.

The main difference is that the workaround does not work for hard reboots/crashes, until you have automatic sign in enabled, does this make sense?

[Nonary]

I mean I even have this script available to download, just follow the instructions and you're basically good to go honestly

[mdrichardson]

I don't want the virtual monitor to become the primary monitor, ever. I want the virtual monitor to always be disabled when not in use. I appreciate your help, but your script doesn't work for my use case.

[Nonary]

I don't want the virtual monitor to become the primary monitor, ever. I want the virtual monitor to always be disabled when not in use. I appreciate your help, but your script doesn't work for my use case.

You are clearly misunderstanding what the script does. Either way from a technical level I can tell you that this feature request would be exceptionally challenging because of how DXGI works, there are certain steps that can only be done once in the lifetime of the process. We would have to setup a mechanism that essentially reboots sunshine and reconnects it, which is a lot of work for something that can be easily scripted like I've explained.

[kinchahoy]

Thanks all! Very much appreciate the discussion around this! It looks like the way to handle this is: 1). Do not set a specific display in Sunshine 2). Leave your desktop operating on your personal monitor only (dummy hdmi disabled) 3). Start a Moonlight stream 4). Let the Do script activate the dummy HDMI as a secondary monitor 5). When the Do script unwinds, deactivate the dummy HDMI Here is my question then - can the Do script tell Sunshine to attach to the secondary screen (dummy HDMI) and not the primary screen (personal monitor) once it is active? Obviously the normal way to do this does not work (since the dummy HDMI is disabled at the start)? This would solve the problem that folks like Michael and I have. If not, then I think our feature request - to run some kind of script BEFORE checking that the display is available - may be the only way to handle streaming to a TV while having a single personal monitor that is unaffected.

…

On Wed, Aug 16, 2023 at 8:21 PM Chase Payne ***@***.***> wrote: I'd call that a workaround, but not really meeting the feature request. I'd like my monitor arrangement to stay as close to "normal" as possible while streaming to prevent any window shifting. If that can be done, great. If not, I'll settle for the virtual monitor becoming the primary when streaming. To be clear, I've been aware of this workaround. My chiming into the OP was just to +1 this as a feature request. Even if we did this feature, you're always going to have window shifting. Window shifting is a side effect of disabling a monitor. It is done intentionally by the OS to prevent users from accidentally leaving Outlook for example on the other monitor and not be able to recover it. Doing what you want will take more than just shifting the do command before the monitors are captured basically. — Reply to this email directly, view it on GitHub <#1506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRT7PMYH4UC2CYCGK6NHGDXVWE4HANCNFSM6AAAAAA3E6F3UE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Nonary]

Sunshine does not currently have any other types of commands that execute before you start a stream entirely. I understand your request, but I just don’t know how it would be valuable.

Simply because there would be many issues with a lot of games if you had two screens active. For example, your mouse would travel to the other screen on accident.

Perhaps, if you can stress the value of this, then we can consider you know, maybe prioritizing it as a feature. however, as a developer myself, I really don’t see my self even coding this out one day because I just don’t really see any value in it.

[mdrichardson]

There doesn't have to be two screens active when streaming. The point/value is to be able to disable the streaming monitor when not streaming so that if you have a pc that you primarily use for other things, you don't have to worry about the mouse or windows going to the dummy plug or virtual monitor that is only needed for streaming.

[kinchahoy]

Thanks for trying to understand the need / usecase Chase. I understand that it would be a bit of work to add a "on Moonlight stream request" script hook. Let me try and motivate the usecase: I believe I'm representative of a huge fraction of Sunshine users - folks with a desktop with one monitor who would like to stream to a TV or ipad (with a very different resolution), and would like to seamlessly do both. Right now, as long as I remember to run a script before switching away from my desktop, I have a near perfect experience. The script activates the dummy plug for the TV/iPad, and both Steam and Sunshine attach properly to the secondary display. I can put down my controller, come back to my desk, tap out an email and go back to my game without any issues (this is the advantage over switching completely or just streaming the main display). However, remembering to run the script before and after each gaming session is onerous.Similarly keeping the dummy plug active all the time is a terrible experience (you'll lose your mouse etc.). I'm reasonably sure that if you add this feature and clearly document how to use a dummy plug for streaming to a TV/iPad, you'll find a significant share of Sunshine users will end up using this setup. It allows streaming to a distant device without messing up the primary monitor / computer experience.

…

On Wed, Aug 16, 2023 at 10:12 PM Chase Payne ***@***.***> wrote: Sunshine does not currently have any other types of commands that execute before you start a stream entirely. I understand your request, but I just don’t know how it would be valuable. Simply because there would be many issues with a lot of games if you had two screens active. For example, your mouse would travel to the other screen on accident. Perhaps, if you can stress the value of this, then we can consider you know, maybe prioritizing it as a feature. however, as a developer myself, I really don’t see my self even coding this out one day because I just don’t really see any value in it. — Reply to this email directly, view it on GitHub <#1506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRT7PPBPMG4MENOSW2ELVDXVWR4VANCNFSM6AAAAAA3E6F3UE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Nonary]

I would say it is doubtful we would change Sunshines command execution for this, but what we could do is make it so that if users have a monitor configured and its not active, it should still execute commands. In other words you'd still be on your own on figuring out how to script it.

[mdrichardson]

Yeah, I think something like this would work. Ideally, it would then retry connecting to the monitor, too. But if I just need to try connecting twice (after the first one runs the activation script), that's fine, too.

[kinchahoy]

That would be perfect and would solve our problem! Happy to write up a how-to as a guide for others when we have the feature / tweak.

…

On Thu, Aug 17, 2023 at 12:03 AM Chase Payne ***@***.***> wrote: I would say it is doubtful we would change Sunshines command execution for this, but what we could do is make it so that if users have a monitor configured and its not active, it should still execute commands. In other words you'd still be on your own on figuring out how to script it. — Reply to this email directly, view it on GitHub <#1506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRT7PNFIVABMV2U5DYXQLLXVW65JANCNFSM6AAAAAA3E6F3UE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Nonary]

I double checked the code and it was changed recently to essentially probe for displays and configure encoders prior to streaming because of situations where primary monitor could change and things like that. It's not going to be a simple change as I originally thought, it would involve having to add special commands that execute prior to the stream starting.

When the day comes for extending prep commands (to do things like on stream pause, on stream resume, etc) it's definitely a consideration to add a before encoder initialize command I guess.

[kinchahoy]

Taking a quick look at the codebase, could proc_t::execute() be refactored into two parts, a proc_t::preexecute() that only does the steps to the run_command do script step and execute()? That would allow you to call preexecute() before checking the displays via the probe_encoders call in nvhttp.cpp? That also seems conceptually like the right flow - allowing the script to get things right before you check displays / encoders.

[Nonary]

Its not as simple as shifting a line of code up, it requires a lot of refactoring because of how execute() is doing too much.

Specifically, do/undo commands are intentionally designed to prevent the stream from starting. It's definitely possible, it's just time consuming to refactor all of that and then having to test and making sure it doesn't break the linux side of things as well.

It's really not a question of difficulty, just tedious and time consuming, basically.

[kinchahoy]

Understood. Appreciate you taking the time to understand and evaluate the request Chase. I hope you'll soon have the capacity to make this improvement.

…

On Thu, Aug 17, 2023 at 9:27 PM Chase Payne ***@***.***> wrote: Its not as simple as shifting a line of code up, it requires a lot of refactoring because of how execute() is doing too much. Specifically, do/undo commands are intentionally designed to prevent the stream from starting. It's definitely possible, it's just time consuming to refactor all of that and then having to test and making sure it doesn't break the linux side of things as well. It's really not a question of difficulty, just tedious and time consuming, basically. — Reply to this email directly, view it on GitHub <#1553 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRT7PNF7EG2NRQBNSEOG73XV3VJDANCNFSM6AAAAAA3UHQCRY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lastb0isct]

To add to this @Nonary, though i'm not sure if this is already possible (i have looked into it but couldn't find an answer) -- I have a UW display as my main display. I have my computer set to sleep, I Wake-on-LAN it and then my UW is not connected anymore because it has turned off due to power savings mode (This will not always be the case but happens on occasion). It would be nice to have the dongle disabled/enabled on the do/undo command so I don't have to go turn on the display to make the nircmd.exe setprimarydisplay command to work since it is expecting my primary to be my UW...would get around this by the disable/enable.

[Nonary]

Use the script to do that, currently I don’t have plans to refactor Sunshine to do this as a script can server 99% of users in most cases.

https://github.com/Nonary/MonitorSwapAutomation

Doesn’t mean this feature will not be done, just saying I will likely not work on it. Someone else in the community is free to take this feature request of course.

[lastb0isct]

Thanks for the quick response! Will test this out...hadn't seen these scripts before.

[lastb0isct]

Does this powershell script take into account if one of the monitors isn't available (i.e. my ultrawide is turned off and can't be detected by Windows at the time)?

[Nonary]

It does, it will poll in background and wait for your display to be available and restore it back once possible. As long as you don’t log off or reboot the Pc prior to returning to your desk

[lastb0isct]

Fantastic! Thank you!

[jimmt41]

Create a pre-command to change the primary display and do not specify a display. The command I use is cmd /C displayswitch.exe /external. The post command I use to revert back is cmd /C displayswitch.exe /internal

[andrewburgess]

Running into this a bit as well with the IddSampleDriver to enable HDR.

I'm using (WS Display Settings) with a streaming specific profile that is applied with a Do command, which enables the virtual display and sets a specific resolution

• If I launch a streaming session while the virtual display is "turned on" (setup as "extend desktop to this display"), then HDR comes through as expected.
• If I launch a streaming session where the virtual display starts as disconnected (setup as "disconnect this display"), then the HDR comes through extremely distorted. (Client reports the stream is HDR, but looks like HDR on an incapable display)
  • If I then open display settings while streaming and toggle HDR off and then back on, the stream corrects itself and renders as expected.

I assume it's something to do with not having HDR capabilities when the stream is started because the virtual display hasn't become available yet. If I could execute my monitor configuration switch before the stream actually began, then I think the HDR capabilities would be available.

I'm currently working around it by making the Virtual Display as small as possible and tucking it off in a corner, but just wanted to provide another use case where a command that can execute before the stream started/display info was gathered could be useful.

[fidoboy]

Running into this a bit as well with the IddSampleDriver to enable HDR.

I'm using (WS Display Settings) with a streaming specific profile that is applied with a Do command, which enables the virtual display and sets a specific resolution

• If I launch a streaming session while the virtual display is "turned on" (setup as "extend desktop to this display"), then HDR comes through as expected.

• If I launch a streaming session where the virtual display starts as disconnected (setup as "disconnect this display"), then the HDR comes through extremely distorted. (Client reports the stream is HDR, but looks like HDR on an incapable display)

  • If I then open display settings while streaming and toggle HDR off and then back on, the stream corrects itself and renders as expected.

I assume it's something to do with not having HDR capabilities when the stream is started because the virtual display hasn't become available yet. If I could execute my monitor configuration switch before the stream actually began, then I think the HDR capabilities would be available.

I'm currently working around it by making the Virtual Display as small as possible and tucking it off in a corner, but just wanted to provide another use case where a command that can execute before the stream started/display info was gathered could be useful.

I apologize in advance for the digression, but I can't help but ask about the issue of using HDR with a driver that simulates a non-existent screen. I've done some tests in the past with lddSampleDriver being able to create and use a fake display with a res of 4K. However I can't get it to work with HDR features so the streamed game doesn't works as desired into the destination 4K HDR screen.

Obviously the issue is that the computer screen doesn't have HDR support but the client where the game is being streamed does have it. So it could be extremely useful if anyone can help with the issue. What I want to know if it's possible to disable all real displays, enable the fake display created with lddSampleDriver (or another screen emulator method) and have it working with HDR. I want to avoid to use a HDMI or DP dongle if it can be acomplished with a software method.

Thanks in advance,

[andrewburgess]

This repository contains a modified IddSampleDriver with HDR support https://github.com/itsmikethetech/Virtual-Display-Driver that I've been using

[fidoboy]

Amazing. Thanks a lot. I'm going to try it.

[fidoboy]

Oops. It seems that HDR only works with Windows 11 that I never will use. Isn't there alternatives for Windows 10?

[Nonary]

Not that I am aware of no, a lot of the bug fixes and performance improvements focused towards gaming are also Windows 11 exclusive.

[fidoboy]

What a pity. I'm afraid that I'll never use Windows 11. But many thanks for the info anyway.

[chrismegyeri]

I am encoutering the same issue as listed above, and I do believe the "global" pre-application launch scripts need to have some additional functionality to execute prior to conducting a "check" for an active monitor as I will describe.

In my use case, I have a mixed usage PC which I am trying to run as a sunshine streaming server/workstation with a single Ultrawide monitor and a HDMI dummy plug for "switching" when actively streaming, thus turning off my main monitor

The use case is as described on my Linux host running wayland.

1. My PC will send its primary monitor into power saving mode after 15 mins

2. When I open up moonlight to stream from sunshine, I expect the following to occur

3. Wake up my monitor, I am currently using

   "busctl --user set-property org.gnome.Mutter.DisplayConfig /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode i 0"
   This command wil not currently execute, prior to checking for an active monitor, as such sunshine will show an error "Failed to initialise video capture/encoding. Is a display connected and turned on? (Error503)"

   Of course its not detected, I am trying to "wake it, so this error won't occur without having to be physically going to my PC to wake it up.

4. Assuming the PC is woken up the following would then occur
   4.1 The HDMI dummy plug would be enabled "sh -c "gnome-monitor-config set -LpM HDMI-1 -m '2560x1440@119.998' -s 1""
   4.2 The Primary screen would be disabled, thus showing a blank monitor

5. After completing the session, sunshine would terminate and run revert the config by enabling the primary monitor, and disable the dummy plug
   5.a sh -c "gnome-monitor-config set -LpM DP-1 -m '5120x1440@120.049' -s 1"

As this is perfectly doable from a capability perspective, its mearly the logic behind the pre commands and when they execute. My sugested for my particular use case would be to have a global tick box to "Wake monitors" prior to launching sunshine application, or alternatively allow for pre-application scripts to allow the method I described.

[BlackCharon142]

I recently ran into this problem and I'm surprised this is still an issue
I have very little understanding of how to code things but based on what I can see in the logs this could've been solved by just implementing a button to toggle if the command should run before everything else or after everything else, right?

[gschintgen]

I'm hitting the same issue on Linux with KMS capture. My display goes to standby after some time but I can wake it via ssh (see below). Unfortunately that same command I'm sending off via ssh can't be used in Sunshine's since it's doing the display detection before the Do command has a chance to wake the screen.

In order to not just repeat what has been said before, I'd like to document my own workaround. I'm using a Nodered Dashboard (on my homeserver) to call the following little script via ssh:

#!/bin/bash
ID=$(loginctl list-sessions | grep seat | awk '{print $1}')
loginctl unlock-session $ID

It unlocks the session and it wakes the screen.

This is perfect when the PC is two floors away from the living room TV where I only have a controller but no keyboard for entering passwords.

If it weren't for that workaround I don't know how I could (reliably) use Sunshine. I would probably have to disable the display power management and only have a single timer for putting the whole PC to suspend automatically. But for various reasons I don't want to do that. (I remotely access VMs and containers on the PC. For that use case I often want the PC to be turned on but the display should go to sleep since I'm working remotely on it via ssh, vscode, etc.)