This tweak fixes the equality testing so that it works reliably with rotated displays. It turns out that the NVIDIA driver doesn't set the TVFormat option reliably whenever it rotates a display. During testing I've had the TvFormat option set to 557 and 320 for the exact same nonitor, and it really seems to depend on what the driver decided it wanted to set (the landscape mode is always 555).
I expect that it is due to the portrait sizes not being 'standard' TV sizes, so it is trying to find the best match, but in any case the variation in this setting doesn't appear to affect us using the profile... it only affects the equality tests uses to check if a particular profile is in use.
For this reason I've excluded the TvFormat from the equality testing so that the variation caused by the driver doesn't break the Equals check.
There was an error that occurred in NvAPI_SetDisplayConfig when attempting to go from an NVIDIA Surround to a non-NVIDIA Surround setup on a machine that has multiple video cards installed in it. This is due to the fact that the NVIDIA driver only sees the displays connected to NVIDIA video adapters.
The previous DM logic tried to set the DisplayConfig after switching to or from a Surround display profile, but this would fail when returning from a a Surround display profile on Win 10 devices. It appears that the NVIDIA driver AUTOMATICALLY disables all additional displays in windows when it returns from a Surround profile. This simple fact means that the DisplayConfig won't be applied properly, and it errors with an NVAPI_INVALID_ARGUMENT error. This doesn't actually matter though, as the WinLibrary comes to the rescue.
WinLibrary can see all the video adapters available, and so will turn the required displays back on and set them up just right! We *may* lose are some specific DisplayConfig parameters abeing set as part of this process, but I'm not totally sure about that as WinLibrary is basically feature parity with the DisplayConfig settings as far as I can tell.
The fix is to look specifically for the NVAPI_INVALID_ARGUMENT error when attempting to set the NvAPI_DisplayConfig, and if this happens we check if we were going from a surround profile to a non-surround profile. If that is true, then we simply ignore that error. WinLibrary then clears up that problem and everything proceeds as normal.
This should (fingers crossed) fix#119!
This change also makes it far faster to grab and set the tabaskbar settings from registry, though this logic may not detect some Windows 10 formats which appear to be LOCALDISPLAY(\d,\d,\d\d) settings which I've never seen before. It should be generally much faster and more reliable.
This function isn't needed, but seems to be unreliable when it's used. So diabling it within NVIDIALibrary to reduce the chances of there being memory errors thrown.
The NVIDIA Driver seems to not like any other SetTopoFlags except NONE. There is a CTD if anything is selected :(. So as a workaround I will leave send a NONE SetTopoFlag so DisplayMagician can work.
Also have updated the Display Profiles Window logic so that it repositions DisplayMagician in the center of the screen on the primary display. This has to be done when changing Display Profiles using the Apply Button, as the display coordinates change, and sometimes this results in the current position being off screen. This was causing confusion amongst users. But now just always moving to the middle of the primary screen I can always be sure that the UI is visible.
NVIDIALibrary and WinLibrary were too rigid in their equality testing, which meant that there was a problem when Windows reordered the displays in the path. This happens randomly when changing to cloned displays, and after a reboot. This would muck up the equality testing, which would prevent users selecting the display profiles. This has now been corrected (as far as we can tell so far).
There is a slight chance that further testing may find other parts of the Windows Display Config that randomly change and need to be updated. Thanks Microsoft.
This DRS Support is just reserving a space for the future addition of DRS Settings pulled from the driver. This will allow the recording of settings listed in the 3D Settings within the NVIDIA Control panel.
There were some issues with memory deallocation where AllocateHGlobal memory was being freed incorrectly with FreeCoTaskMem. This was causing issues with subsequent memory allocations.
The Advanced Target Info object returned by the NVIDIA driver points to memory outside the allocated memory. I need to figure out how the NVIDIA code allocates the memory, so I can account for it on return.
Let's see if this works. It will skip grabbing the color data and the HDR data on monitors that don't support it. That includes the following connections types: VGA, COMPONENT, SVIDEO, DVI, COMPOSITE. Any other connection types will attempt to get HDR and Colour settings, so that we'll automatically support whatever new technology arrives in the future. Should help fix the last part of #76.
The NVIDIA HDR colour logic was flawed, and wouldn't always apply properly. These logic changes now set the NVIDIA HDR colour back to windows controlled each time so the settings are at a known inital logical state. Then winlibray can set the windows HDR mode, and NVIDIA can set the NVIDIA HDR mode.
Did a HUGE amount of testing with the amazing help of @domenic as part of #41, and we finally got the right configuration sorted out! This update is a reflection of the changes required.
Added empty DisplayConfig dictionary and CustomDisplays list to the Display Profiles JSON format, as I'm going to need it in a while when I add the integer scaling.
This integrates all the library enhancements that I've been working on for the last 2 weeks into DisplayMagician. This fixes $47, #46 and possibly others.
Weird error where having a clone causes an extra 'zeroed out' entry in the Windows Display Modes sequence. This change modifies the Windows mode info checks to allow for this situation.
Brought over all the latest working code from NVIDIAInfo, AMDInfo and CCDInfo. This includes the new split between the NVIDIA and AMD specific layout, and the NVIDIA and AMD specific color application, so that the video application logic goes like this:
1. Apply NVIDIA Surround or AMD Eyefinity and any 'pre' windows settings
2. Apply the Windows Display Layout
3. Apply the NVIDIA or AMD 'post' windows settings e.g. driver specific color overrides
This new process works.
There was a problem with the unused display config containing null values on save, which meant that the JSON would be invalid when loaded in the next time. The fix was to ensure that both NVIDIA and AMD both were filled with a default config when a new profiles was created. This means that the real config would overwrite whichever config was needed, and the JSON file would work as all objects were populated correctly!
This is the first actual working version of the AMDLibrary from AMDInfo v1.0.0. This is the first time that all 3 different video libraries are in DisplayMagician and working (mostly). The AMD Screens structu creation logic in ProfileItem still needs to be updated to cope with the AMD Eyefinity configuration, but it at least defaults to the windows one at the moment so it doesn't crash (whew).
Also managed to bugfix the recent libraryfolder.vdf parsing change that a recent Steam Library change oforced on us. The logic wasn't working, and so the parsing didn't work, which in turn caused an exception when it came time to look up the game shortcut validity.
THere was an unneeded check that prevented the NVIDIA HDR settings being applied when it should have been. This in turn meant that the display profile equality matching wasn't working as the applied display profile was sufficiently different to the one selected and applied that it wouldn't match, and would instead display the brand new profile interface. This has been corrected now.
Windows changes the display source order which mucks up the equality matching in DM. This change attempts to mitigate that fact.
There were also errors in the HDR settings captured, which indicate that the HDR changes weren't finishing before they were being recorded. This change attempts to take care of that too.
All tests so far seem to work, so lets see how things go!
Equality works until we return from a surround profile to a non-surround profile. At this point the displays are reordered by windows, and the windows display configus don't match any more. Addtionally, it looks as though we need a 0.5 second pause between applying the configuration, and reading the new config. There appears to be a difference between HDR before we changed to the surround proile and after we've returned, and that's not a good thing!
