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!
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.
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!
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.
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.
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!
Completed the Shortcut and Display Profile
hotkey UI interface to a satisfactory level.
The hotkey settings are stored with the
profile JSON for profiles, and with the
shortcut JSON for shortcuts. This means
they load correctly and are remembered
between runs of DisplayMagician.
Next step is to actually register the Hotkeys
so they work, and then allow them to be
replaced or removed when they are changed.
NVIDIA just updated their device driver, and
as part of those changes, it changed the name
that was reported by the NVIDIA driver. This
impacts our profile matching, as we previously
used the name that it returned in the fingerprint
we store about connected displays. This change
removes that name so that it will correctly match
on the old driver or the new driver.
NOTE: This requires recreating the profiles though!
This change was to separate 'Equals'
(which checks for exactly the same) with
'Possible' (which checks that the connected
displays are available to use. Should make
the profile comparison a lot more accurate.
This time adjusted profile matching
so that it will work no matter what order
the displayidentifiers or paths are stored
in. Should be a bit slower but a lot more
reliable.
Fixed the Profile.Equals logic so that it
could detect the difference between
Surround and non-Surround triple screen
configurations. Now seems to work fine.
Also adjusted the ProfileAdapter so that
the profile imagelistview works correctly.
Moved to using the UUID rather than the
name to allow users to change the name
without affecting the UUID. That was a
change I should have made AGES ago.
Relaxed the profile matching logic to
use my looser displayidentifier logic
as it is more likely that connections to
a display is changed rather thant the
display paths, resolution or anything like
that. Will use this as an experiment to
see if it works or not.
Also fixed the shortcut renaming errors
by searching for the UUID, not the shortcut
name which is the pretty much the way
I should have done it in the first place!
Added a button to save a profile shortcut
to the Windows desktop. This will enable
people to quickly change to another display
configuration if they want to using a desktop
display. This will work even if they are unable
to get admin rights to install the background
popup menu.
Installer works, but there are a few issues with it.
- It doesn't register the DesktopBackground COM server
- It doesn't create a start menu shortcut with the AUMID
- It doesn't check for .Net Framework 4.8 or later
- It doesn't try to install .Net Framework 4.8 or later if not there
- It doesn't have any customised backgrounds...
- It doesn't ask to run DisplayMagician when install is finished
