AMD Eyefinity now works just as well as the NVIDIA implementation... probably even more robustly than the NVIDIA one. Fixes#37 and #21. I'll now start on some other bugfixing and features in preparation for DisplayMagician v2.0.0
WIth @scowling incredible help I managed to get the AMDLibrary to work, even if the user removes the Eyefinity configuration. AMDLibrary is now clever enough to automatically recreate the SLSMap even if the user has deleted it! This is a great robustness improvement, and will help reduce my support calls greatly!
Now ProfileItem loads properly from JSON file, which means that the profile matching works, so DisplayMagician now matches the profile if it's current.
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.
Issue when creating screens structure while NVIDIA setup is still partway through its changeover as it causes an exception. Now capture that exception and ignore it, as the screens structure is updated correctly when the screen finally settles down.
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!
Mostly works now! Only bit still needing work is the Avtive profile detection to detect the non-surround profile when we return from surround. I think it's to do with the windows display number changing :(. I need to check that.
The derived ProfilteItem classes were an unnecessary distraction and wasted time I could be spending on other things. This set of changes are the first part of removing those derived classes and moving to a single ProfilItem class again, but with different configuration slots within it. Makes equality comparison SO MUCH EASIER!
I am a lot closer at the moment, but there is some bit of logic matching that is escaping me. I think I'm just too tired at the moment, and I need a sleep. I bet this will seem simple in the morning.
This (hopefully) should fix#38. Big thanks to @DragRedSim for their help. This will attempt to use the new library file liocation if it's available, and will fall back to the older config.vdf discovery mechanism if it doesn't find the new file.
Found an underlying problem of using the OutputID for displayIdentifier matching as the outputID changes after each reboot. CHanged the DisplayIdentifier to record the type of the connection to the display, which stays the same even if the OututID changes. Also made the ProfileItem.Equals look for DisplayIdentifier ids and match them even if they are in a different order. This seems to happen some times, and I'm not sure why the NVIDIA driver does it!
It was set to Error instead of Trace! Corrected now.
Also corrected some incorrect log message descriptions that will mean I look at the right code when I see the errors. There were all the same (as I copied a lot of the code).
Tested ok so far! Manages to cope with surround dual screen with another standaalone screen fine, and copes with individual screens as well as just surround screens. Tested playing a game shortcut, and it sworks with that too. It also changes the display background as per the profile settings as was intended! So pretty much everything seems to work fine so far.
I will do a bit more testing, then will probably provide a test version to a couple of testers to try and find errors. I need to try and make this a bit more robust.
Used new derived class equality class from https://codinghelmet.com/articles/equals-override which helped me understand the logic for deriving equality between base classes and derived classes. It has now exposed another error in the way FORCED_VIDEO_MODE is being applied and that is now something else I need to fix!
This feature will allow users to bypass the automatic driver detection functionality so that they can at least force the use of the built-in Windows driver if NVIDIA or AMD ever have an issue with their drivers.
Added in the ability to map the Windows CCD Display name to NVAPI DisplayId, which will make it possible to use that information within DisplayMagician.
Partway through having the Screens properly populated for the NVIDIA surround screen setups, but have struck an issue with the extra non-surround screens in a combined surround and non-surround screen setup. The additional non-surround screens don't have any X & Y positions set within the mosaic config, which means I should really be using the WIndows config details, but there isn't anyway to identify which windows screen path matches which nvidia display ID. THe only way to do this is to start storing the NVIDIA displayconfig too.
This is the initial windows desktop functionality, and may work. I've added it to the earlier version of DisplayMagician, but I'm not sure I'll release it. This will instead probably be part of v2.0.0.
Amazing! This is the first working version of DisplayMagician using the new NVIDIA and Windows CCD library. It works properly, and now I can start to tidy up some of the additioanl functionality I need to sort out before a release. I also then need to work on the AMD library as well!
This is the initial version of the spanned screen bitmap drawing. It woks by showing one giant screen, but it currently doesn't insert any information about the individual screens that make up the spanned screen at all. I'm going to add that improvement at a later date, because the main thing is to get the new libraries up and running, and used by people.
Still have an issue where the 'Equals' doesn't detect that there is a different primary screen, so it won't let me save a new profile for the slightly changed display settings.
NVIDIA Profiles can be created, JSON file saved ok, and the bitmaps and icons are drawn correctly and showin in the Display Profile window. The problem comes when the DisplayProfiles_2.0.json file is loaded. JsonConvert causes an exception trying to populate ProfileBitmap, and I can't figure out why!
