Added all of the OK ADL statuses to be considered as successful. Should minimise the chances of things going wrong if there is a little issue like the display driver being busy, or if the display is fine but needs to wait for the next modeset.
AMDLibrary had an error that caused issues due to a missing call to get a valid default config. WinLibrary had an issue where it wasn't applying the GDIDisplaySettings correctly after a reboot. This has now been fixed.
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.
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.
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!
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.
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!
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.
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).
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!
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!
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!
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.
Added some basic CCD library functionality
to be able to set Windows displays directly
from the code. This will enable future native
HDR support through windows, as well as
allow positioning and screen setup to work
better through here than via the AMD driver.
Will still need to work on AMD Eyefinity support
once this is completed.
Now have the DisplayProfile storing the minimal set of
data that it needs. It also recreates the Screens list (used
for creating profile bitmaps and icons) and recreates the
DisplayProfileBitmaps each time at present. I will add some
logic to deerialise the bitmaps again at a later date once
I've compeleted actually applying the AMD display confs.
Now works with single screens and similar
so that they show correctly on the page without
being hidden by foreground stuff. Still might
make the DisplayView larger if it makes sense.
Have managed to get a working displayview
for AMD (not working in spanned mode) and
currently playing with the colours and layout.
Once I have something locked in, I'll troubleshoot
the ProfileDisplay file writing.
Trying to figure out a video card agnostic way
of generating the display icons fo both standard
and spanned displays. Still trying to figure out
exactly which AMD ADL calls I need to make to
get all the information I need. It is NOT very well
documented. It's actually really annoying! AMD
need to do better.
Trying to make the DisplayView and ProfileIcon
image drawing logic more generic so that it will
work with NVIDIA, AMD , Intel and Windows video
card drivers. Having to reverse engineer the amazing
wok that Soroush did with this stuff. I just know that
I'm going to break this before I fix it, but I really think
this is needed in order for this new video card
separation refactoring to work. This is going to take a
while I feel!
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!
