This thing does not work

[unphased]

I followed the instructions. when sunlight client connects, it opens a cmd window and nothing happens. the computer's resolution does not change.

i'm actually a bit confused about what even is supposed to happen. I ASSUME the whole idea is that upon connecting with moonlight, sunshine will auto switch the pc's monitor to have the matching resolution as the client.

But even in the instructions we can see the "undo" field for the custom command is blank.

You also have 4 commands listed in the screenshot and the readme fails to explain what the rest of them are.

All in all the documentation could have been done a lot better.

[sofmeright]

I updated the documentation.

In the commands field in Sunshine you should be referencing the SunshineIntegration.bat that comes in the release folder.
You also should configure qres or an application that can change the resolution and refresh rate for your session.
(If paths to say Qres, SunshineIntegration.bat, etc. contain spaces then you'd want to enclose the full path within ~ "".)

What I use currently and also trying to break it down for you:

(Target App: VirtualDisplayDriver via my custom script / For the Need: Make sure the active display driver is configured with an option for the clients current resolution and refresh rate):

C:\IddSampleDriver\SunshineIntegration.bat %SUNSHINE_CLIENT_WIDTH% %SUNSHINE_CLIENT_HEIGHT% %SUNSHINE_CLIENT_FPS%

(Target App: QRes.exe / For the Need: Set the hosts display resolution and refresh rate to match the clients values.)

cmd /C C:\_Staging\_Utilities\QRes.exe /X:%SUNSHINE_CLIENT_WIDTH% /Y:%SUNSHINE_CLIENT_HEIGHT% /R:%SUNSHINE_CLIENT_FPS%

Note: This tool works only with the 24.9.11 Beta Virtual Display Drivers; alongside that particular version or earlier of the drivers this tool is known working without issues.

What is supposed to happen?:

The intent is that when you start your app in Moonlight from each of your client devices; the virtual display should automatically engage your session with the desired resolution and if you also setup qres it should change the display to your target resolution and refresh rate when you begin the stream from the client device. I use this so I don't have to manually enter any resolutions and can still use funky native resolutions like on my Surface Pro 9. It does work and it makes the GUI pretty much obsolete, its a seamless experience... I am more than happy to troubleshoot with you if you run into further issues so we can ensure this last release I put out is truly stable and working for legacy GUI compatibility with the Indirect Display Driver Sample Dev projects that haven't strayed from the sample's structure.

Status of the VirtualDisplayDrivers (VDD? ~ the main project this project provides a GUI for):
The project originates from the Microsoft Indirect Display Sample Driver and since December of 2024 there is a stable release that is no longer a dev sample but now a production release and as such some work needs to be done to support the current release. Development is planned on an ASAP basis to support the current stable release that came out last December. There have been some delays due to unrelated issues, currently I am the sole developer of this project. Also, I lost my local production cluster / homelab and am rebuilding my local dev environment / lab from scratch for some months. I do expect that I will be able to at least roll out support for the new driver hopefully by Q2. I am currently using this 24.9.11 release myself in the meantime.

[unphased]

I am not sure if the fiddling i did with this, in particular the driver that this tool auto downloaded, had an impact on the following, but, for me, I am using Sunshine set up without any integrations configured (e.g. no apps under Command Preparations), and here is what I observe:

• As long as for a given monitor or HDMI dummy plug I have a suitable resolution configured under nvidia control panel resolutions list, in this case 3456x2160 (without notch) for my 16" Macbook Pro XDR display,
• I can connect and manually run QRes from Terminal with that res specified, and it will properly switch the desktop resolution to this. If the PC happens to be connected to a 4K monitor all 4K monitors I've tested properly letterbox it down! My next step will be to insert a call to QRes only under the Command Preparations in Sunshine config to achieve this automatically.
• upon disconnecting the moonlight session, the monitor automatically switches back to 4K resolution. I have to assume this is something built into recent Sunshine versions. Because it is very nice that I do not have to trigger QRes again to get this.
• when a 1080p monitor is connected QRes will refuses to switch to this resolution because the 1080p monitor rightfully cannot handle it. This doesnt bother me as much as i thought it would. I assume the virtual display driver could come into play in this situation.

My assumption is that if the virtual display driver is active and actually working, if i ever open up the display settings in windows i should see it as an extra new monitor. Well I never once observed this so perhaps i never got it working.

Either way I'm quite happy to move forward not worrying about anything virtual because I'm very satisfied with being able to get 3456x2160 as long as I have either my dummy plug inserted on HDMI or my 4K DP monitor powered on, and if not when for some reason I have my 1080p monitor plugged into this PC, the experience streaming at 1080p remains compelling regardless. Somehow it has taken me this long to put this setup through its paces and now that I have a bluetooth gamepad connected on macOS (it's compatible with iOS as well so I'm excited to try that out next with my ipads) i'm able to get a full resolution, 4:4:4 chroma 120hz experience over the network with nearly imperceptibly low latency (at least until jitter hits typically when I receive text messages). it's really impressive.

Thanks for offering to help me troubleshoot, but, I think at this time I'm making the call that I will simply use a hardware approach for now which means I can avoid the need to deal with the virtual display driver.

What I can say is that the driver appears to be obtained by this script so that means it should be the correct version...