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.
The taskbar location detection process was taking way too long when clicking on the 'view current display' button on the display window. Do I have had to disable the taskbar location detection logic for now until I can work out way of doing it without waiting for registry changes (as it is done now). This was required in order to be able to detect the taskbar location registry settings so that we could store them to use them later.
This taskbar registry detection doesn't work at present as it is highly unreliable, and it delays the user experience for the other 99% of the time. Its just not worth the effort right now, so parking this for now.
To temporarily disable this being used, I've simply forced the WindowsLibrary fastscan mode to be enabled (fastscan being on means it won't do taskbar location scanning).
Fixes#153. AMD display profiles with rotated displays will now show that rotation properly in the display layout. Last commit included NVIDIA and Windows, and this now means all supported video cards now have this feature so the issue can be closed.
Added display rotation awareness to the Screen awareness parsing. This code is used to create the generic 'Screens' structures that are used to generate the display profile icons. This partially fixes#153. I still have to add the AMD configuration equivalent!
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.
We now properly set the default JSON values for everything except Display Profiles, which should avoid crashes to desktop if we miss setting a value from it's default in the future. This should help with application robustness.
Just noticed that the Settings, Display Profiles and Game Shortcuts all had different json.net settings for reading and writing across all the modules. Have now standardised across them to make them act the same way.
WinLibrary currently waits 5 seconds if it can't read the taskbar registry, and then it tries again. This is because based on my testing, if a screen layout changes, windows takes up to 20 seconds to update registry to record this fact. We have to wait until windows has finished 4 times before we are sure to have passed the 20 second window.
This is likely the delay you have mentioned. I *think* that I can slightly speed this up. We only MUST to do this delay when we are recording the config (i.e. creating a new display profile), and other times it's kind of a nice to have. So I've attempted to speed this up using a 'fastScan' option for the WinLibrary GetActiveConfig function. This will enable it to only query once for the general scans of the active config, and if there is a problem getting the data it will just accept that fact and will still return quickly. But it will still take up to 20 seconds when creating a new display profile as it is REALLY important we get that data correctly.
Fixes#129
Updated the NLog exception handling to make use of the additional logging options released recently. This will help provide me with more details when users create the Support ZIP File.
This is required so that the undocumented DISPLAYCONFIG_SOURCE_DPI_SCALE_GET Windows CCD call is given the correct information by Windows 10/11. It gives an abnormal number on some hardware if this is not set. What we do now is set the process DPI context to "System Aware" on boot, but when we are either getting or setting the Windows DPI settings, we quickly swap to "Monitor Aware v2" DPI context, before swapping back to "System Aware" when we're done. This *should* return the correct per monitor settings.
The NVAPI and Windows APIs were checked multiple times in a row due to a logic error. THis has been partially corrected, but needs a lot of work to straighten it out.
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.
There is a possibility that there are two displays with the same UID. This happens with software created displays such as SpaceDesk and Superdisplay. This means that we need to try and figure out which screen is the right screen, and then when we know which screen we were really wanting to
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.
DM will now warn users they will need to recreate their Display Profiles again. I really hope this is the last time I have to do this to my lovely users.
TaskBarLayout now catches exceptions recording the taskbar location and handles them properly. It will skip any screenss that it cannot access the taskbar information for. The Screen layout generator for NVIDIA, AMD and Windows have all been updated to handle having no taskbar layout information (it just assumes the taskbar is down the bottom of the screen).
Hopefully fixes#114
This was a major error that somehow slipped through previous work. WinLibrary was only partially patching the Windows Display Config when it was being loaded, and that resulted in some parts of the Windows Display Config not working after a windows reboot. This should now be fixed!
Fixes#103
IMPORTANT: This patching means that DisplayMagician is able to use your existing Display Profiles, but there is a catch! DisplayMagician won't be able to detect that your old profiles are currently in use... in other words DisplayMagician will constantly think that you have a new Display Profile until you save a copy of the DisplayProfile again.
This occurs because DisplayMagician now gets and compares the NVIDIA 3D Settings and there is no way for us to figure out what previous 3D settings were in use when you set up previous display profiles. For that reason we'll just need you to save new Display Profiles.
