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.
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!
Moving to a situation where each library has
it's own ProfileData structure which will require
me to break the existing Profile structure.
This will be better once finished, but it could
be a month before I get this rewrite finished :/
We have to do this as we will be moving
to a new video card library-based way of
getting the Display Profiles information.
This is designed to enable me to add new
video card drivers in the future, such as
Intel, in order to support 'combined'
video screens,
I finally figured out how to check for displays
that are selectable, but aren't in use. It's not
as striaght forward with AMD ASL library as
it is with NVIDIA's driver, thats for sure.
Seem to have fixed the exceptions based on
all the testing I've been doing. So there is at
least that!
This is a lot of learning about Pinvoke
and the way to marshal c structures
into c# managed structures when passed
as out.
This is all a lot more indepth than I was
hoping it was going to be!
There is a long road ahead of me, but
at least some of the structure is working
now! We can at least call the AMD ADL
library and get results returned back!
Tried to add the first SLS map config get function into
the ADL.cs file, as well as all the supporting data
structures. Time will tell whether this will work or not!
The startPrograms UI would error when someone tried
to remove an unsaved startprogram from the FLP.
This has now been resolved.
Also managed to update a warning in the logs when
a program starts and the original exe is a loader that
loads another exe then closes itself. I've provided that
warning in the log file now.
Added exception protection around the video
card identifier errors to at least allow
DisplayMagician to kind of keep working even
if there are errors in the NVIDIA drivers. This fix
was brought about to get around problems with
NVIDIA RTX 2080Ti cards when using NVIDIA
driver 466.11. This fix should allow users with
cards that report data incorrectly to recreate new
DisplayProfiles, and then change all their shortcuts
to use those new Display Profiles. DisplayMagician
should then start working again. Fixes#7.
NOTE: This problem is a workaround for a broken
NVIDIA driver. Once NVIDIA find out and fix it, then
you will need to recreate your Display Profile again
and change all your shortcuts to the new Display
Prrofile in order for your shortcuts to work again.
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.
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!
It was erroring when loading games into
a blank shortcut screen. This was stopping
us being able to select any games at all.
Fixed another problem with Shortcut.IsValid
causing exception when loading a profle
that no longer existed. It now will correctly
report that the shortcut is isvalid.
Fixed the profiles selection so it doesn't change
when you swap screens. Made the 'View
current display' button refresh the profile validity
too, so that a user now only has to change their
display settings in Windows and then swap back
DisplayMagician and click the View Current Display
button and the profiles will be updated.
Combined DisplayMagicianShared logging into
the main log file to simplify log reporting for the
future. Also started adding info and debug
statements to the program to make the debug
level log work well for troubleshooting. This is
going to take a LONG time to complete, but will
be worth it in the end.
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
