Added empty DisplayConfig dictionary and CustomDisplays list to the Display Profiles JSON format, as I'm going to need it in a while when I add the integer scaling.
Found some calls that were bypassing the video library state buffering I'd put in place earlier. This should generally make DisplayMagician faster and minimise the number of log entries written to DisplayMagician.log.
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.
As I'd changed the profile config to buffer it within the libraries themselves, ApplyProfile wasn't telling the libraries to update their config. Therefore they thought they were still on the original display config, and that meant that ApplyProfile didn't revert the profile after the application had closed. This is now fixed.
As we now only copy across some of the GDI display settings, we aren't able to have really tight matching on the GDI part of the Windows display profiles. For this reason, I loosened off the Equals test so that it would match on the functions that we change within DisplayMagician. The profile matching now works correctly.
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.
The profile updating logic wouldn't work with the new way of buffering the display config, which means that when swapping back to DisplayMagician after updating the display layout wouldn't automatically update the display profile. Now, it forces this.
Changed Profiles to use new methods for profiles detection provided by the new video card library updates for NVIDIALibrary, AMDLibrary and WinLibrary. This should make DisplayMagician faster as there is less repetition.
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.
There have been such large changes with v2.1.0 that I've had to move to a new file display profile format again :(. I'm really hopeful this will be the last time, as it seems to cope with all the different display layouts, colour settings, hdr etc.
Weird error where having a clone causes an extra 'zeroed out' entry in the Windows Display Modes sequence. This change modifies the Windows mode info checks to allow for this situation.
This will ensure that existing display profiles will at least load. Anyone with refresh settings changes or BPC or other device context settings will need to recreate their display profiles.
Updated the profile so that it applies the new split video application process properly to DisplayMagician profiles. Should fix#45 (we shall soon see).
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.
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!
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!
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 :/
Decided that the DisplayProfile changes would
have to be breaking changes if I was going to
add HDR support, and be able to handle adding
future video cards from different manufacturers.
This all requires a change to the DisplayProfile
format. So now this is going to use a file called
DisplayProfiles_2.0.json rather than a file called
DisplayProfiles_1.0.json. This is because the
profiles will need to be generated again from
scratch, as they will all be completely different
to the format in DisplayProfiles_1.0.json.
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!
Have now go the required data, but for some
reason AMD is returning two valid adapters
when there is actually just one in the system!
Could be a problem with the device installation,
but I will need figuring out how to either remove
duplicates, or figure out the information to use as
a filter for ignoring one of the adapters.
We now have enough data for me to identify
all the connected display devices, and to
generate a display identifier which will work
no matter if AMD Eyefinity is enabled or not!
This should allow me to generate an display
identifier that will work like the NVIDIA ones.
Trying different ways to get a list of all the connnected
displays via the AMD ADL library. It seems pretty
onerous at the moment, and seems like there is still a
lot of work to go :/. AGS may have been the better
way to go, but ADL at least had a C# example for me
to start with!
Need to add Display Device info extraction.
Have created consts for the connector types
in c#, but now need to add the logic to decode
the ADLDeviceConfig returned value!
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!
ADL2_Display_SLSMapConfig_SetState
ADL2_Display_SLSGrid_Caps
ADL2_Display_SLSMapIndexList_Get
ADL2_Display_SLSMapIndex_Get
Have to try and sort out the delegates and
the other bits to match the rest of the
AMD provided library entries.
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!
Changed the process stopping logic
to make it more relable, and also make it
much more likely to actually stop the
programs even if they do things like
launch other programs and stop themselves
Added more helpful instructions
Added a link to the Example Start Programs
settings on the wiki by clicking on a button
in the ShortcutForm itself.
Added helpful MessageBox telling people
they need to select a Game Shortcut in order
to run, edit, delete or save it. Also included
text about the mouse right-click menu.
Clarified text on the StartProgramControl.
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.
Managed to break some logic when trying to
add robustness.... effectively doing the
opposite of what I was trying to do :/. Now
*should* be fixed, but we shall see with more
testing.
OriginLibrary wasn't added to the validity
checking, so no Origin games would work.
Also added a LOAD more trace logging with the
Origin library so I can see from the logs what's
happening. Also updated the version to 1.0.5.1.
And finally, removed unneeded validityrefresh
from the base ShortcutItem constructor as it
is refreshed later anyway. Should speed up
object creation a little.
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.
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.
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.
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.
