-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new API to modify display devices for Windows #2582
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2582 +/- ##
=========================================
- Coverage 9.57% 8.80% -0.77%
=========================================
Files 97 115 +18
Lines 17586 19289 +1703
Branches 8336 9275 +939
=========================================
+ Hits 1683 1699 +16
- Misses 13174 14529 +1355
- Partials 2729 3061 +332
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Due to recent changes to the docs, all the doc changes to |
b81c566
to
e31f0ae
Compare
Very little note while I was going through my comments.. But HDR control may require a "extra" mode to plug into nvapi (which somehow I just noticed you already pulled in as a dependency?) for games that do their magic through it. |
For now this PR will focus on interacting with Windows API only and enabling "global" HDR setting only. |
I can't wait for this PR to get merged, I can't stress how amazing this is, thank you! If I were to take this, build it, install, would everything work as expected aside from a bug here or there? Assuming this would be the case but just want to verify since I'm not involved in this project. |
I play almost every day with this dev on Windows 11 and I have no problems. You can download it with your eyes closed |
@bradleycundari as moi952 just mentioned, you can download Github artifacts. However, they are needlessly hidden for someone without some previous knowledge: |
This comment was marked as off-topic.
This comment was marked as off-topic.
Please don't hijack this PR for off-topic discussions. |
d00e2fc
to
16febac
Compare
@kanjieater Since I do not know which monitor is gone, I cannot just stop trying to restore the initial configuration. However, what about an intermediate phase?
|
@FrogTheFrog sorry for interfering, but do we even want to mess with manual restoration of multiple displays? |
Originally i was thinking: |
Well, I have multiple displays that are mostly always inactive. I do not want them to be restored when we "extend" it on the way out. Also, what if the extension is incomplete and uses currently enabled devices OR fails (because not all devices are available, for example), then we are in the same stupid situation where "sleeping" displays would have to be restored manually. Thus, I chose to at least keep trying. |
The problem is sleeping displays - we cannot differentiate between disconnected ones (physically) and the ones that are off. So, a simple user would end up with a monitor that is permanently off since it could not be restored. As for what you have suggested, that's what I'll be trying to do - restore as much as possible, but still keep trying to restore until either used acknowledges that it's time to stop or we succeed. |
Windows stores display configurations (resolutions and placement on the virtual desktop) on the per monitor set per topology basis. If you have any monitor disabled in one topology, switching to another topology and back will restore that too. That's why it will also resolve the newly mentioned issue, windows stores separate configurations for both |
We have talking about this in private and for now, we stick to the current, but a little improved approach. Future changes/adjustments will be possible once the PRs are merged. |
Do you know when you will have time to finish and when it will be released? |
When it's done. Please don't manipulate people into giving deadlines, since they're all unpaid volunteers. Thank you. |
I'm not manipulating anyone, I'm just asking the question to know when it will be finished because that also allows us to have the latest developments. |
I'm not saying you're doing it intentionally, god forbid. But it's still emotional manipulation, the person will naturally try to give to the closest reasonable date possible, then feel bad if they will be failing to meet it for whatever reason. Extra stress with no gain for all parties involved. |
Please try windows build from: The non-existent displays will not block partially reverting active displays. But it will still try to do it every 5 seconds and as I've said before, you need to tell Sunshine to stop if you're happy with current displays. Note that this build is based on new stuff - you need to re-enable options in Sunshine and there is no resolution/refresh rate remapping yet |
I've been using the update as you recommended @FrogTheFrog . It did fix all of my issues, just wanted to confirm that - thanks for updating & sharing |
Random query for this, in the inital PR @FrogTheFrog states that the list of available monitors is outputted as part of Sunshines startup, could this list just be piped into a selection box in the UI for the user to select from instead of hunting through logs etc? This would create a better user experience and also likely help to reduce user error by putting the wrong value in. |
Someone was already working on it little by little, however for this PR it's out of scope |
This comment was marked as off-topic.
This comment was marked as off-topic.
@sofmeright thanks for sharing. It's a bit out of scope of this PR, which will use https://github.com/LizardByte/libdisplaydevice ... but I can add your tool to awesome-sunshine -> LizardByte/awesome-sunshine#13 |
Hi, It never switches back to the right screen when the stream cuts out, but I did anything and installed a version on your repo https://github.com/FrogTheFrog/Sunshine/actions I installed the latest, the stream freezes in 10 seconds, so I switched back to the version of this MR, and it no longer wants to switch to the specified screen, the logs (attached) indicate: [2024:10:08:11:02:54]: Info: Changing display modes to: If you have time to help me with all the work you have that would be great, otherwise I will wait for the release in production. Thanks for your work |
Please try a build from this PR: Be aware that you will need to re-do the configuration as I have moved some config stuff around. |
Thanks for your super fast response. I saved the configuration, I saw that the part that allows to match the resolutions / frame rate was moved so I put back the frame rate matching, moreover it could be interesting for the HDMI dummies to have a maching "if greater than 60 set to the client's frame rate", 60 being a value that can be configured, it avoids doing 90 => 60, 120 => 60, 144 => 60. It does not switch to the specified screen, except that I do not have the impression of having an error in the logs. And I have freezes after 10 seconds, then it comes back 10 or 20 seconds later and so on. I specify that I am on AMD drivers 24.9.1. Sorry for the inconvenience, maybe it can help to debug. I'll give you my configuration too. (j'ai du la transformer en .txt car le .json ne passe pas dans github) Thanks |
You have an empty remapping entry in the config, please delete this empty entry. Also lets move the discussion to that othe PR please. |
When will this #2582 be merged into the master branch? Will that replace the old \.\DISPLAY1 output_name completely or is it compatible with both device id and display id? I also fetched it |
It will replace it completely, therefore the merging for this PR will only start after a new Sunshine release.
This PR/build is no longer maintained and is left open only as a placeholder. If you want the latest, most-up-to-date build, check FrogTheFrog#2
No, it's already printed out in Sunshine logs. |
Thank you for the explanation. So I should git clone this https://github.com/FrogTheFrog/Sunshine/tree/libdd-part-3 and checkout the branch libdd-part-3? Is this branch then also up to date with https://github.com/LizardByte/Sunshine or does it differ much? |
Yes, you can checkout that one and build, but you don't have to. You can also just download the binaries that are built by github. I keep the branch up-to-date with Sunshine with my changes put on top of whatever new comes in. I usually rebase on Sunshine after some important stuff is added to Sunshine, like right now - they fixed the ffmpeg issues. |
Where can I find the build releases with your fork? On your page there are no releases published and on the sunshine page your branch isn't merged yet. Also, to understand it correctly, your method guarantees that the display device name is a fixed and unique value which is static as is and not like the previous display name which was dynamically generated by Windows right? Would ist be complicated to build a tool like the dxgi-info.exe for your device names because I want to create a initial setup script and without such a tool you have to start and stop the sunshine process to get these values. It is possible but it would be better to get these values without starting sunshine for this. |
See #2582 (comment) on how to download binaries for forks. You can build such tool yourself if you want. The functionality has been exported to a library which you could use. An here's even an example code: https://github.com/LizardByte/libdisplaydevice/blob/48ca85e8e7c3c01fef5db7f0befced7ea21d6238/tests/unit/windows/test_win_playground.cpp#L53 |
Should I close this then? |
Nay! I shall do it myself (once am back at the PC). |
Summary of the current state:
|
This is a continuation of the #2032 PR after a rebase fiasco...
Description
New changes allow for Sunshine to control display devices on Windows, such as:
It also moves away from the
\\.\DISPLAY1
-like configurable output names to proper that are pretty persistent (IDs changed a little after I reinstalled my GPU drivers, after DDU).The applied changes are saved additionally saved to a file in case the PC dies or something so that Sunshine can undo the changes once it is started again.
Screenshot
Example of the new options exposed to the user:
Type of Change
.github/...
)Checklist
Branch Updates
LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.
Known issues (all resolved)
IDD HDR driver displays high-contrast colors when the display is activated and was inactive before. Seems to be a driver issue, since it does not happen with HDR dongle. A workaround would be to reset all the HDR states to off and then on again, but I don't think we should implement this workaround for this.Sound fails to reset back to whatever was used before after the stream ends if a new display (without the same sink) was the only active display.