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: https://github.com/LizardByte/Sunshine/discussions/1535

[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.

[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.

[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)

[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.

[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.

[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.

[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 <LizardByte/Sunshine#1506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRT7PNFIVABMV2U5DYXQLLXVW65JANCNFSM6AAAAAA3E6F3UE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[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.

[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 <https://github.com/LizardByte/Sunshine/discussions/1553#discussioncomment-6757616>, 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.

[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)?

[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?

[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 '[email protected]' -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 '[email protected]' -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.)

[MrHighVoltage]

I agree that this feature would make it quite a bit more useful, especially for Linux users.

As commented by @gschintgen, I'm using a similar approach, but instead of unlocking the session, I turn the screens on using kscreen-doctor:
WAYLAND_DISPLAY=wayland-0 kscreen-doctor --dpms on
For this, I always need a ssh session before, which is quick on a computer, but can be quite the annoying overhead on a smartphone, for example.

Running this command in Sunshine before any checks/encoder setups etc. are done would make for a much leaner experience.

[FiveYellowMice]

I'm running into this issue too. Since it looks like nobody is working this and the maintainer welcomes contribution. I'm drafting a PR implementing this feature: LizardByte/Sunshine#3821 . Comments welcome.

[Nonary]

A complete re-work of prep commands is currently in progress, which will address this problem as well as add more advanced capability like executing scripts when a stream is paused or resumed.

LizardByte/Sunshine#4023

It's in alpha right now, but is stable enough to actually work.

The UI needs some major polish and backend has to be cleaned up, other than that it is working as designed so far.