Add new API to modify display devices for Windows #2032

FrogTheFrog · 2024-01-17T08:38:14Z

Description

New changes allow for Sunshine to control display devices on Windows, such as:

changing display mode (resolution and refresh rate);
activating/deactivating displays;
enabling/disabling HDR;

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

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Dependency update (updates to dependencies)
Documentation update (changes to documentation)
Repository update (changes to repository files, e.g. .github/...)

Checklist

My code follows the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

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.

I want maintainers to keep my branch updated

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

cmake/targets/common.cmake

src_assets/common/assets/web/config.html

cmake/dependencies/unix.cmake

dbz400 · 2024-01-19T00:25:12Z

Wonder does it work on hyper-v guest ?

FrogTheFrog · 2024-01-19T08:44:31Z

Wonder does it work on hyper-v guest ?

Should work, but you'll have to try it yourself.

dbz400 · 2024-01-20T02:11:27Z

@FrogTheFrog Any artifact that I can test out ?

FrogTheFrog · 2024-01-20T09:23:06Z

@FrogTheFrog Any artifact that I can test out ?

You'll have to build yourself.

src_assets/common/assets/web/config.html

ReenigneArcher · 2024-01-30T16:15:22Z

I have a review in process, but there is a lot to review here so it might take me a little bit.

In the meantime could you add the doc pages for the new source code files?

FrogTheFrog · 2024-01-30T20:15:26Z

I have a review in process, but there is a lot to review here so it might take me a little bit.

In the meantime could you add the doc pages for the new source code files?

I've added the rst files, but I get the following warnings:

/home/frog/Desktop/Sunshine/docs/source/source_code/src/display_device/display_device.rst:4: WARNING: Error when parsing function declaration.
If the function has no return type:
  Error in declarator or parameters-and-qualifiers
  Invalid C++ declaration: Expected identifier in nested name. [error at 43]
    NLOHMANN_JSON_SERIALIZE_ENUM (hdr_state_e, { { hdr_state_e::unknown, "unknown" }, { hdr_state_e::disabled, "disabled" }, { hdr_state_e::enabled, "enabled" } }) using hdr_state_map_t
    -------------------------------------------^
If the function has a return type:
  Error in declarator
  If declarator-id with parameters-and-qualifiers:
    Invalid C++ declaration: Expected identifier in nested name. [error at 29]
      NLOHMANN_JSON_SERIALIZE_ENUM (hdr_state_e, { { hdr_state_e::unknown, "unknown" }, { hdr_state_e::disabled, "disabled" }, { hdr_state_e::enabled, "enabled" } }) using hdr_state_map_t
      -----------------------------^
  If parenthesis in noptr-declarator:
    Error in declarator or parameters-and-qualifiers
    If pointer to member declarator:
      Invalid C++ declaration: Expected '::' in pointer to member (function). [error at 41]
        NLOHMANN_JSON_SERIALIZE_ENUM (hdr_state_e, { { hdr_state_e::unknown, "unknown" }, { hdr_state_e::disabled, "disabled" }, { hdr_state_e::enabled, "enabled" } }) using hdr_state_map_t
        -----------------------------------------^
    If declarator-id:
      Invalid C++ declaration: Expecting "(" in parameters-and-qualifiers. [error at 41]
        NLOHMANN_JSON_SERIALIZE_ENUM (hdr_state_e, { { hdr_state_e::unknown, "unknown" }, { hdr_state_e::disabled, "disabled" }, { hdr_state_e::enabled, "enabled" } }) using hdr_state_map_t
        -----------------------------------------^

/home/frog/Desktop/Sunshine/docs/source/source_code/src/display_device/parsed_config.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/config:4.
Declaration is '.. cpp:type:: config'.
/home/frog/Desktop/Sunshine/docs/source/source_code/src/display_device/parsed_config.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/display_device/display_device:4.
Declaration is '.. cpp:type:: display_device'.
/home/frog/Desktop/Sunshine/docs/source/source_code/src/display_device/parsed_config.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/rtsp:4.
Declaration is '.. cpp:type:: rtsp_stream'.
/home/frog/Desktop/Sunshine/docs/source/source_code/src/display_device/session.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/display_device/display_device:4.
Declaration is '.. cpp:type:: display_device'.
/home/frog/Desktop/Sunshine/docs/source/source_code/src/display_device/settings.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/display_device/display_device:4.
Declaration is '.. cpp:type:: display_device'.
/home/frog/Desktop/Sunshine/docs/source/source_code/src/platform/windows/display_device/settings_data.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/display_device/display_device:4.
Declaration is '.. cpp:type:: display_device'.
/home/frog/Desktop/Sunshine/docs/source/source_code/src/platform/windows/display_device/settings_topology.rst:4: WARNING: Duplicate C++ declaration, also defined at source_code/src/display_device/display_device:4.
Declaration is '.. cpp:type:: display_device'.

No idea how to fix them... Maybe it does not like forward declaration?

ReenigneArcher · 2024-01-30T22:46:48Z

Yea, it doesn't like duplicates. I don't know how to solve it either at this point.

This is what I've done in these cases. https://github.com/LizardByte/Sunshine/blob/nightly/docs/source/source_code/src/platform/linux/graphics.rst?plain=1

I guess, try to have the main files documented... and the secondary ones can have the todo.

FrogTheFrog · 2024-01-30T23:22:38Z

Yea, it doesn't like duplicates. I don't know how to solve it either at this point.

This is what I've done in these cases. https://github.com/LizardByte/Sunshine/blob/nightly/docs/source/source_code/src/platform/linux/graphics.rst?plain=1

I guess, try to have the main files documented... and the secondary ones can have the todo.

I can only include the main file at this point. Also, it seems to be having problems with templated macros (according to google) and there is no way to suppress warnings for NLOHMANN_JSON_SERIALIZE_ENUM out of the box it seems, so I have to also "todo" that file too...

FrogTheFrog · 2024-02-04T11:01:28Z

Squashed and rebased the branch

Nonary · 2024-02-05T15:28:49Z

@ReenigneArcher I have reached out to Frog explaining the main technical issues with trying to restore and swap monitors before and after stream, which I encountered with my script.

What is the goal of this PR?

I presume to improve the reliability of switching monitors, because currently the display names can change, causing Sunshine to break.

However, the solution proposed does not actually improve reliability or fix the problem because:

In Windows, Display IDs are subject to change due to the system's device enumeration process. This means that whenever there's a driver reinstallation or significant changes to the system, Windows will reassign new instance IDs to displays, based on their configuration and connection sequence. Consequently, these IDs are not permanent and should not be relied upon as unique identifiers.

What does that mean?

Using the device identifiers is just as unreliable as the display names and it will change, causing the same behavior as today. Once they change, Sunshine will be unable to swap to the monitor until the user resolves the issue by updating the new identifiers.

I have had two others try the same thing and ultimately all of us end up back to the same issue, there's no way to reliably swap monitors in Windows, without saving the settings in a profile fashion and then restoring them, much like https://sourceforge.net/p/monitorswitcher/code/HEAD/tree/MonitorSwitcher/MonitorSwitcher/

This is something we could do in Sunshine of course, but its hard to implement in terms of making it easy for the user to do and it also doesn't work for Linux.

Nonary · 2024-02-05T15:36:15Z

My proposal here is to remove the display swap code portions and keep the resolution change and HDR portions as these are more reliable and users would benefit from including these in Sunshine.

We could support the capability of swapping monitors but the only reliable way I've found is restoring a profile like mentioned earlier, more work needed in the PR for that basically.

FrogTheFrog · 2024-02-05T16:36:59Z

My counter arguments:

The IDs change

Yes, they indeed change after driver has been reinstalled. However, not by much. In my case only 1 number changes in the:

\\?\DISPLAY-HDR1500-5&4fd2de4&2&UID4354-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}

string. It's the one before the &UID4354 part.

The IDs are used for lookup only and are "made up" by me, we could use anything arbitrary as long as we could identify the device. Maybe we could simply omit that changing number.

Incorrect IDs

I do not use ids that change every time the system is restarted like sourceInfo.adapterId. I use monitorDevicePath which seems to be pretty consistent for me, but might need to adapt it somehow?

Removing the display swap code portions

There is no need to do it in my opinion as we still need to use the IDs and it simply comes as a bonus (read the next section).

Restoring the profiles

There is no need save the "complete" profiles as they are already saved by Windows. The way Windows saves the profiles is per an active display topology.

Let's say you have 3 monitors A, B and C:

[A, B, C] (all monitors are extended) - we have CONFIG1;
[A, B] (2 monitors are extended, 1 is disabled) - we have CONFIG2;
[A, C] (2 monitors are extended, 1 is disabled) - we have CONFIG3;
[{A, B}, C] (2 monitors are duplicated, 1 is extended) - we have CONFIG4;

You MUST ensure that you are modifying the correct config first! So, if I switch to topology [C] and modify it, I make sure to ONLY revert the changes if we are still in the same topology (will try to switch back to it if not). Otherwise, you can loose positional information (where displays are relative to each other) and other information that was not meant to be changed.

You can easily test this with Windows Settings app, simply change the resolution/position to something random in the current topology, then enable/disable some device and see that the resolution is now different from what you've configured before

Now, if you connect a display D, Windows would probably automatically activate the topology [C, D] or maybe some other combination based on what the latest was when D monitor was active.

My only question is what to do when we are reverting changes and the topology [C] is not longer valid. Currently I try it once and give up, but we could technically do it until it becomes available (still waiting on feedback regarding this).

Conclusion

We still need to use IDs of some sort to first find out about the topology configuration we are dealing with, but we should agree on what is persistent enough. Keep in mind, I don't store previous settings for long, only until we can undo them (or try to).

FrogTheFrog · 2024-02-05T17:28:37Z

I did some investigation into the IDs and these were the results:

INITIAL         : \\?\DISPLAY-ACI27EC-5&4fd2de4&2&UID4352-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DIFF. PORTS     : \\?\DISPLAY-ACI27EC-5&4fd2de4&2&UID4358-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DDU + NEW DRIVER: \\?\DISPLAY-ACI27EC-5&4fd2de4&3&UID4358-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}

INITIAL         : \\?\DISPLAY-HDR1500-5&4fd2de4&2&UID4357-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DIFF. PORTS     : \\?\DISPLAY-HDR1500-5&4fd2de4&2&UID4354-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DDU + NEW DRIVER: \\?\DISPLAY-HDR1500-5&4fd2de4&3&UID4354-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}

INITIAL         : \\?\DISPLAY-LNX0000-1&1aafb3d5&2&UID256-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DIFF. PORTS     : \\?\DISPLAY-LNX0000-1&1aafb3d5&2&UID256-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DDU + NEW DRIVER: \\?\DISPLAY-LNX0000-1&1aafb3d5&2&UID256-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}

...

+ 2 more IDD HDR entries (LNX0000)

For the physical monitors the part \\?\DISPLAY-ACI27EC-5&4fd2de4 and \\?\DISPLAY-HDR1500-5&4fd2de4 seems to be consistent. The virtual display seems to be only influences by its own driver reinstall (not shown here).

Since I have this data (and some more available):

DEVICE ID: \\?\DISPLAY-ACI27EC-5&4fd2de4&2&UID4352-{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
DISPLAY NAME: \\.\DISPLAY1
FRIENDLY NAME: ROG PG279Q
DEVICE STATE: PRIMARY
HDR STATE: UNKNOWN

I could make my own ID, something like:

\\?\DISPLAY-ACI27EC-5&4fd2de4-ROGPG279Q-<edidManufactureId>-<edidProductCodeId>-<connectorInstance>

However, I sadly don't have 2 identical displays so I don't know if they would be unique enough (connectorInstance number should ensure the identical display uniqueness). I could maybe add some other EDID metadata, but I need help with this one...

cgutman · 2024-02-06T03:27:56Z

I have 3 Dell S2417DG monitors on my workstation and this is what they look like in WinObj.

Interestingly the Container ID seems to be the most stable identifier for the monitors across connections (and even across GPU vendors). It's not perfect either but it's a lot better than the Device Instance ID. Here is the Device by Container view with non-present devices enabled to show previous instances of the monitors with different instance IDs.

The bottom 2 are actually Microsoft Basic Display Adapter devices (probably created during a driver update or fresh install), so those won't be relevant to us.

It looks like Microsoft actually provides built-in support for Container ID generation using EDID data with WDDM.

In some cases, the display device might not contain a container ID. In this case, Windows automatically generates a unique container ID by using the manufacturer ID, product ID, and serial number obtained from the Extended Display Identification Data (EDID). Because these values are unique, the container ID is also unique. Windows 8 provides a DDI that passes the same information to the WDDM driver so that it can be passed to the audio driver to generate the same container ID.

FrogTheFrog · 2024-02-06T10:50:22Z

I did some more experimentation and here are the results (using https://github.com/FrogTheFrog/Sunshine/tree/id-test as a playground):
before.txt
switching wires around.txt
ddu + fresh driver install.txt

To me it seems that the first part for InstanceID is stable:

DISPLAY\HDR1500\5&4FD2DE4&3&UID4354 -> DISPLAY\HDR1500\5&4FD2DE4

According to chatGPT 5 is a bus number and 4FD2DE4 is used to distinguish device on the same bus (I assume GPU or something).

Container ID is stable for physical devices @cgutman, but is bonkers on the virtual ones (since the don't have enough edid information I assume).

ConnectorInstance seems to change when reconnecting devices physically, it seems to relate to GPU port somehow (could be unstable).

So, I would suggest to use:

<STABLE_PART_OF_INSTANCE_ID>-<edidManufactureId>-<edidProductCodeId>-<edidSerialId>-<edidMonitorDESC1>-<edidMonitorDESC2>-<edidMonitorDESC3>

OR if we have edidManufactureId != 0 and edidProductCodeId != 0, use

<STABLE_PART_OF_INSTANCE_ID>-<ContainerID>

else:

<STABLE_PART_OF_INSTANCE_ID>-<HASHED_EDID>

Here I have connected my monitor with DisplayPort and HDMI at the same time:

deviceMonitorPath: \\?\DISPLAY#ACI27EC#5&4fd2de4&4&UID4357#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
displayName:\\.\DISPLAY2
friendlyName: ROG PG279Q
outputTechnology: 5
edidManufactureId: 26884
edidProductCodeId: 10220
connectorInstance: 1
instanceId: DISPLAY\ACI27EC\5&4FD2DE4&4&UID4357
edidSerialId: 16843009
edidMonitorDESC1: K5LMQS021930
edidMonitorDESC3: ROG PG279Q
edidUUID: {7d8852fa-c2bb-51d8-9c7b-d1dfdb7ba281}
ContainerID: {c50822ab-0095-5b80-bbc1-310e4136d665}
---------------------
deviceMonitorPath: \\?\DISPLAY#ACI27EC#5&4fd2de4&4&UID4352#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
displayName:\\.\DISPLAY1
friendlyName: ROG PG279Q
outputTechnology: 10
edidManufactureId: 26884
edidProductCodeId: 10220
connectorInstance: 0
instanceId: DISPLAY\ACI27EC\5&4FD2DE4&4&UID4352
edidSerialId: 21930
edidMonitorDESC1: #ASN9J6nNITbd
edidMonitorDESC3: ROG PG279Q
edidUUID: {0acd25df-9a9b-56a1-b932-5ef25fb16207}
ContainerID: {6d5aae8a-cb7e-5e6a-855a-7c9a887983b2}

and both edidUUID and ContainerID and are different and stable. Maybe we could just use:

<STABLE_PART_OF_INSTANCE_ID>-<HASHED_EDID>

With a fallback to

deviceMonitorPath

if edid is not available?

EDIT:

Here's the same output from the previous testing (with edidUUID this time):
before2.txt
switching wires around2.txt
ddu + fresh driver install2.txt

It seems very stable

EDIT:
Got more data from another user with nearly identical displays:

another_set_of_data.txt

The proposed id still seems to be unique.

ReenigneArcher

Your c++ skill level is far above mine so I can't provide much meaningful review on that part (further review will be needed from cgutman and/or other team members). The documentation blocks look good and the code seems well structured.

Once this gets merged are you going to available/willing to fix bugs that come up due to these changes? I'm a bit worried about that since this grows the project code by around 20%. If you could add any unit testing, that would be greatly appreciated and ease my worries a little.

Some methods that look like easy wins in testing:

parse_resolution_string
parse_refresh_rate_string
parse_resolution_option
parse_refresh_rate_option
parse_hdr_option
to_string

A virtual display is also prepped to be setup in the CI, it just needs to be enabled. Just remove this line to enable:

Sunshine/.github/workflows/CI.yml

Line 866 in 116e592

if: false # todo: DirectX11 is not available, so even software encoder fails

And then you could likely unit test a lot more functions.

.gitmodules

cmake/dependencies/common.cmake

cmake/compile_definitions/linux.cmake

ReenigneArcher · 2024-04-08T21:17:07Z

docs/source/about/advanced_usage.rst

@@ -590,9 +590,35 @@ keybindings
      .. todo:: macOS


Any thoughts on this?

ReenigneArcher · 2024-04-08T21:19:50Z

third-party/nlohmann_json

Can you checkout and commit the latest release/tag of this submodule? https://github.com/nlohmann/json/releases

Should be 9cca280a4d0ccf0c08f47a99aa71d1b0e52f8d03

ReenigneArcher · 2024-04-08T21:24:27Z

src_assets/common/assets/web/config.html

+              "display_device_prep": "no_operation",
+              "resolution_change": "automatic",
+              "manual_resolution": "",
+              "display_mode_remapping": "[]",
+              "refresh_rate_change": "automatic",
+              "manual_refresh_rate": "",
+              "hdr_prep": "automatic",


All of the new config options should be added to the advanced_usage.rst file. The order in that file should be the same as within the config ui.

ReenigneArcher · 2024-04-08T21:26:17Z

src_assets/common/assets/web/config.html

+              "display_device_prep": "no_operation",
+              "resolution_change": "automatic",
+              "manual_resolution": "",
+              "display_mode_remapping": "[]",


display_mode_remapping is out of order, according to the order they are above.

ReenigneArcher · 2024-04-08T21:33:44Z

src_assets/common/assets/web/public/assets/locale/en.json

@@ -139,6 +139,23 @@
    "controller_desc": "Allows guests to control the host system with a gamepad / controller",
    "credentials_file": "Credentials File",
    "credentials_file_desc": "Store Username/Password separately from Sunshine's state file.",
+    "display_device_options_note_desc_win": "Windows saves various display settings for each combination of currently active displays.\nSunshine then applies changes to a display(-s) belonging to such a display combination.\nIf you disconnect a device which was active when Sunshine applied the settings, the changes can not be\nreverted back unless the combination can be activated again by the time Sunshine tries to revert changes!",


I think I'd prefer if \n wasn't in the strings. The translators are not necessarily going to be programmers or understand what \n does.

You could have a few keys for the same item though, just end them with an index number. Then put your line break in the html. I think I did this in another place already if you need an example.

src/audio.h

ReenigneArcher · 2024-04-10T19:52:17Z

Per discussion on discord. Would it make sense to migrate some of this into it's own re-usable library? Kind of like what is being done in #2315 for Linux input.

It might be easier to expand support to Linux and macOS if it were separated. I can create a repo for it in our org?

codecov · 2024-04-16T06:15:32Z

Codecov Report

Attention: Patch coverage is 0.56243% with 1768 lines in your changes missing coverage. Please review.

Project coverage is 5.59%. Comparing base (9d5ee2f) to head (1889b24).
Report is 195 commits behind head on master.

Files	Patch %	Lines
.../platform/windows/display_device/windows_utils.cpp	0.00%	327 Missing ⚠️
src/platform/windows/display_device/settings.cpp	0.00%	286 Missing ⚠️
src/display_device/parsed_config.cpp	0.38%	236 Missing and 20 partials ⚠️
...latform/windows/display_device/device_topology.cpp	0.00%	200 Missing ⚠️
...c/platform/windows/display_device/device_modes.cpp	0.00%	147 Missing ⚠️
src/display_device/session.cpp	0.96%	99 Missing and 4 partials ⚠️
src/display_device/to_string.cpp	0.00%	86 Missing and 9 partials ⚠️
...tform/windows/display_device/settings_topology.cpp	0.00%	95 Missing ⚠️
...tform/windows/display_device/general_functions.cpp	2.73%	70 Missing and 1 partial ⚠️
...tform/windows/display_device/device_hdr_states.cpp	0.00%	46 Missing ⚠️
... and 17 more

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #2032      +/-   ##
=========================================
- Coverage    6.18%   5.59%   -0.59%     
=========================================
  Files          86      86              
  Lines       17548   15346    -2202     
  Branches     8186    6962    -1224     
=========================================
- Hits         1085     859     -226     
+ Misses      14652   13509    -1143     
+ Partials     1811     978     -833

Flag	Coverage Δ
Linux	`?`
Windows	`1.81% <0.11%> (-0.24%)`	⬇️
macOS-12	`8.23% <1.59%> (-0.50%)`	⬇️
macOS-13	`?`
macOS-14	`?`

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/audio.h	`0.00% <0.00%> (ø)`
src/config.h	`0.00% <0.00%> (ø)`
src/display_device/parsed_config.h	`0.00% <0.00%> (ø)`
src/display_device/session.h	`0.00% <0.00%> (ø)`
src/process.cpp	`1.27% <0.00%> (+<0.01%)`	⬆️
src/platform/windows/display_base.cpp	`9.32% <0.00%> (-0.02%)`	⬇️
...latform/windows/display_device/settings_topology.h	`0.00% <0.00%> (ø)`
...rc/platform/windows/display_device/windows_utils.h	`0.00% <0.00%> (ø)`
src/audio.cpp	`1.53% <0.00%> (+0.01%)`	⬆️
src/stream.cpp	`0.89% <0.00%> (+<0.01%)`	⬆️
... and 17 more

... and 44 files with indirect coverage changes

Mostly copied code from LizardByte#2032 to try a PoC for the API I want to use

ReenigneArcher · 2024-05-16T17:41:32Z

I'm converting this to draft until libdisplaydevice is ready

moi952 · 2024-05-26T16:11:17Z

@FrogTheFrog Is this development canceled? 😳😌

FrogTheFrog · 2024-05-26T16:14:54Z

@FrogTheFrog Is this development canceled? 😳😌

No, it's being ported to a separate library with new unit-tests being added, so it's taking a lot of time.

I have decided to rebase the current branch, however the nightly branch has been renamed to master and so the PR was closed automatically...
I will either reopen this PR somehow or create a new draft PR.

moi952 · 2024-05-26T16:27:38Z

@FrogTheFrog Is this development canceled? 😳😌

No, it's being ported to a separate library with new unit-tests being added, so it's taking a lot of time.

I have decided to rebase the current branch, however the nightly branch has been renamed to master and so the PR was closed automatically...

I will either reopen this PR somehow or create a new draft PR.

Ah I was scared, your work is great it will simplify the configuration of sunshine for many people 🙂

And the possibility of mapping resolutions and frequencies to others is excellent!

I think I understood that there was a new version that was going to be released soon, I suppose your development will not be in that version?

Thanks 🙏🏼

ReenigneArcher requested changes Jan 17, 2024

View reviewed changes

ReenigneArcher changed the title ~~[Windows][WIP] Add new API to modify display devices for Windows~~ Add new API to modify display devices for Windows Jan 17, 2024

FrogTheFrog force-pushed the nightly branch from 65720d1 to e5efac2 Compare January 19, 2024 23:22

cgutman reviewed Jan 20, 2024

View reviewed changes

src_assets/common/assets/web/config.html Outdated Show resolved Hide resolved

cgutman reviewed Jan 20, 2024

View reviewed changes

src_assets/common/assets/web/config.html Outdated Show resolved Hide resolved

FrogTheFrog force-pushed the nightly branch from c5c906c to 2166dd9 Compare January 22, 2024 08:39

FrogTheFrog marked this pull request as ready for review January 26, 2024 20:40

FrogTheFrog requested review from cgutman and ReenigneArcher January 28, 2024 11:53

XenHat mentioned this pull request Jan 30, 2024

Blown out color streamed to SDR clients if HDR enabled without a HDR monitor (dummy plug, etc) #1853

Closed

3 tasks

FrogTheFrog force-pushed the nightly branch from 5e0b6e0 to 9e14d4c Compare January 30, 2024 20:14

FrogTheFrog force-pushed the nightly branch 2 times, most recently from 5721f82 to a16089e Compare February 4, 2024 10:59

cgutman mentioned this pull request Feb 6, 2024

Encoder probing performance improvements #2111

Merged

11 tasks

FrogTheFrog force-pushed the nightly branch from b211f68 to 8d53c9b Compare February 8, 2024 22:40

LizardByte locked as off-topic and limited conversation to collaborators Mar 26, 2024

LizardByte unlocked this conversation Mar 27, 2024

LizardByte locked and limited conversation to collaborators Mar 27, 2024

ReenigneArcher mentioned this pull request Mar 28, 2024

Patch 13 #2314

Closed

11 tasks

Nonary mentioned this pull request Mar 29, 2024

Not restoring original config when streaming is stopped Nonary/MonitorSwapAutomation#27

Closed

FrogTheFrog force-pushed the nightly branch 2 times, most recently from f38ad62 to beb97fe Compare March 31, 2024 19:18

ReenigneArcher reviewed Apr 8, 2024

View reviewed changes

LizardByte unlocked this conversation Apr 10, 2024

ReenigneArcher mentioned this pull request Apr 13, 2024

feat: initial framework setup LizardByte/libdisplaydevice#5

Merged

11 tasks

FrogTheFrog force-pushed the nightly branch from f81cb4a to ee86a1e Compare April 16, 2024 06:14

FrogTheFrog force-pushed the nightly branch from ee86a1e to 3b9d417 Compare April 16, 2024 06:18

ReenigneArcher mentioned this pull request Apr 17, 2024

fix: downgrade to gcc 11 LizardByte/libdisplaydevice#12

Merged

11 tasks

ReenigneArcher mentioned this pull request May 1, 2024

feat(ui): list available displays with select #2490

Draft

16 tasks

Hazer mentioned this pull request May 2, 2024

refactor(ui): break down config.html into smaller pieces #2491

Merged

7 tasks

Hazer added a commit to Hazer/Sunshine that referenced this pull request May 2, 2024

build: nlohmann for all targets (copied from LizardByte#2032)

2516960

Mostly copied code from LizardByte#2032 to try a PoC for the API I want to use

Hazer added a commit to Hazer/Sunshine that referenced this pull request May 2, 2024

build: nlohmann for all targets (copied from LizardByte#2032)

f4a8411

Mostly copied code from LizardByte#2032 to try a PoC for the API I want to use

FrogTheFrog force-pushed the nightly branch from 3b9d417 to 1889b24 Compare May 6, 2024 13:56

Add new API to modify display devices for Windows

1889b24

Hazer added a commit to Hazer/Sunshine that referenced this pull request May 13, 2024

build: nlohmann for all targets (copied from LizardByte#2032)

01d530d

Mostly copied code from LizardByte#2032 to try a PoC for the API I want to use

ReenigneArcher marked this pull request as draft May 16, 2024 17:41

FrogTheFrog closed this May 26, 2024

FrogTheFrog deleted the nightly branch May 26, 2024 15:31

FrogTheFrog mentioned this pull request May 26, 2024

Add new API to modify display devices for Windows #2582

Closed

11 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add new API to modify display devices for Windows #2032

Add new API to modify display devices for Windows #2032

FrogTheFrog commented Jan 17, 2024 •

edited

Loading

dbz400 commented Jan 19, 2024

FrogTheFrog commented Jan 19, 2024

dbz400 commented Jan 20, 2024

FrogTheFrog commented Jan 20, 2024

ReenigneArcher commented Jan 30, 2024

FrogTheFrog commented Jan 30, 2024 •

edited

Loading

ReenigneArcher commented Jan 30, 2024 •

edited

Loading

FrogTheFrog commented Jan 30, 2024 •

edited

Loading

FrogTheFrog commented Feb 4, 2024

Nonary commented Feb 5, 2024 •

edited

Loading

Nonary commented Feb 5, 2024

FrogTheFrog commented Feb 5, 2024 •

edited

Loading

FrogTheFrog commented Feb 5, 2024 •

edited

Loading

cgutman commented Feb 6, 2024

FrogTheFrog commented Feb 6, 2024 •

edited

Loading

ReenigneArcher left a comment

ReenigneArcher Apr 8, 2024

ReenigneArcher Apr 8, 2024

ReenigneArcher Apr 9, 2024

ReenigneArcher Apr 8, 2024

ReenigneArcher Apr 8, 2024

ReenigneArcher Apr 8, 2024

ReenigneArcher commented Apr 10, 2024

codecov bot commented Apr 16, 2024 •

edited

Loading

ReenigneArcher commented May 16, 2024

moi952 commented May 26, 2024

FrogTheFrog commented May 26, 2024 •

edited

Loading

moi952 commented May 26, 2024 •

edited

Loading

Add new API to modify display devices for Windows #2032

Add new API to modify display devices for Windows #2032

Conversation

FrogTheFrog commented Jan 17, 2024 • edited Loading

Description

Screenshot

Type of Change

Checklist

Branch Updates

Known issues (all resolved)

dbz400 commented Jan 19, 2024

FrogTheFrog commented Jan 19, 2024

dbz400 commented Jan 20, 2024

FrogTheFrog commented Jan 20, 2024

ReenigneArcher commented Jan 30, 2024

FrogTheFrog commented Jan 30, 2024 • edited Loading

ReenigneArcher commented Jan 30, 2024 • edited Loading

FrogTheFrog commented Jan 30, 2024 • edited Loading

FrogTheFrog commented Feb 4, 2024

Nonary commented Feb 5, 2024 • edited Loading

What is the goal of this PR?

What does that mean?

Nonary commented Feb 5, 2024

FrogTheFrog commented Feb 5, 2024 • edited Loading

The IDs change

Incorrect IDs

Removing the display swap code portions

Restoring the profiles

Conclusion

FrogTheFrog commented Feb 5, 2024 • edited Loading

cgutman commented Feb 6, 2024

FrogTheFrog commented Feb 6, 2024 • edited Loading

ReenigneArcher left a comment

Choose a reason for hiding this comment

ReenigneArcher Apr 8, 2024

Choose a reason for hiding this comment

ReenigneArcher Apr 8, 2024

Choose a reason for hiding this comment

ReenigneArcher Apr 9, 2024

Choose a reason for hiding this comment

ReenigneArcher Apr 8, 2024

Choose a reason for hiding this comment

ReenigneArcher Apr 8, 2024

Choose a reason for hiding this comment

ReenigneArcher Apr 8, 2024

Choose a reason for hiding this comment

ReenigneArcher commented Apr 10, 2024

codecov bot commented Apr 16, 2024 • edited Loading

Codecov Report

ReenigneArcher commented May 16, 2024

moi952 commented May 26, 2024

FrogTheFrog commented May 26, 2024 • edited Loading

moi952 commented May 26, 2024 • edited Loading

FrogTheFrog commented Jan 17, 2024 •

edited

Loading

FrogTheFrog commented Jan 30, 2024 •

edited

Loading

ReenigneArcher commented Jan 30, 2024 •

edited

Loading

FrogTheFrog commented Jan 30, 2024 •

edited

Loading

Nonary commented Feb 5, 2024 •

edited

Loading

FrogTheFrog commented Feb 5, 2024 •

edited

Loading

FrogTheFrog commented Feb 5, 2024 •

edited

Loading

FrogTheFrog commented Feb 6, 2024 •

edited

Loading

codecov bot commented Apr 16, 2024 •

edited

Loading

FrogTheFrog commented May 26, 2024 •

edited

Loading

moi952 commented May 26, 2024 •

edited

Loading