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!
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!
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).
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.
Have almost integrated the new CCD, AMD and NVIDIA
libraries into DIsplayMagician. The CCD library is working
fine. The AMD library is partially completed, but is awaiting
some help from AMD, as it appears one of their driver functions
is broken (or at least incorrectly documented). The NVIDIA
library is currently still under development, but I've still copied
it across so that I could work on the additional profile objects
that need to be prepared in order for this to work.
As I am waiting on a response from AMD, the plan is now that
I will swap over to an NVIDIA based video card in my test machines
and I will start work on the NVIDIA library. The NVIDIA library seems
straight forward compared to AMD, so that hopefully won't take too
long to do. Once that library is compete, I'll test it within NVIDIAInfo
application until its working, and then I'll port it back over to
DisplayMagician. That will then let me complete the last bits of the
integration so that I can complete the last of the NVIDIA tests.
Hopefully by the time all this happens I will have heard back from
AMD and I will be able to continue work with that section of code.
This is part of the new strategy to split the
ProfileItems into different derived clases with
one per Video card technology. The purpose is
to allow each video card driver to produce a
slightly different profiledata section which is
customised to the needs of that video card.
This will allieviate the need for us to extend
the Path object to support AMD, as we'll be
doing the differentiation at each ProfileItem.
Time will tell if this is a better strategy or not.
This is all to do with my even longer term
strategy of devloping video card driver library
files inhouse. This strategy was directly created
just so that I can make changes in my own code
if I need to support some additional features
such as HDR support within the profiles. It is very
difficult to do this if I'm using another video card
library. Much more simple to update my own code!
