Partially through a different refactor to completely change how the taskbar settigns are stored, and the logic behind the application. Should make the taskbar more robust to apply.
Added some checks to temporarily pause any 'getconfig' type activities while we're changing the displayconfig. This should result in less config corruption, and fewer errors when there are timing edge cases.
We are able to patch the taskbar settings in DisplayProfiles without needing to get the users to remake their display proifiles. This changes the messaging to users.
This changes *should* be the last ones needed to get taskbar setting integrated. Fixes#78 (as much as we can fix it).
Works on Win 10, and partially on Win 11. Win11 won't update the main window until explorer.exe is restarted :(. There is talk that an upcoming Win 11 update will change that behaviour.
This change makes the ProfileRepository handle loading json config files from later versions of DM without causing an exception. This will mean that you can install later model config files and still have them work ok.
Used some of Soroush Falahati's amazing code, and now have the potential for storing the taskbar display layout. This unfortunately requires a display config change, so I will need to engineer some backwards compatibility.
The NVIDIA HDR colour logic was flawed, and wouldn't always apply properly. These logic changes now set the NVIDIA HDR colour back to windows controlled each time so the settings are at a known inital logical state. Then winlibray can set the windows HDR mode, and NVIDIA can set the NVIDIA HDR mode.
Found that I was combining Threads and Tasks together...never a good idea. Have moved fully over to a Task based model. Now still having issues with parallelism.
Improved the minimum form sizes for multiple forms to stop them looking bad.
Updated the DisplayMagician and DisplayMagicianShared assembly versions to v2.1.2.0 in preparation for release as the next version of DisplayMagician.
This version adds USB device support, and SuperDisplay detection (it is a way to use an Android Tablet as another windows display).
Also fixes cloned displays so that it uses the path priority rather than relying on HDR settings for mapping the cloned display ID to the real Display ID. This corrects some errors which occurred when some earlier screens didn't support HDR or the advanced Windows colour settings. It will now work in those situations.
Now supports multiple display adapters. Has been tested by @matthex with his 7 screens and 2 display adapters and works. Should fix#60 finally.
Also changed the way that cloned display configurations are patched. Was using the HDR structure previously as that contains a direct mapping, but of course it completely breaks if HDR information isn't supported by the monitor, or provided over the connection technology used. So the changes I made now use the display path priority order to figure out which cloned monitor belongs to which item.
Firstly, the UID's are pulled from the physical displays so that we have a list of them. We then go through the paths, and for each target we check if there is a matching physical UID. If there is NOT a matching physical ID, then it is a cloned display target. We store that for later.
Next, we go through the paths again, and we figure out which physical displays are NOT in use as display targets. When we have that list, we then map the left over physical displays to the cloned displays in path priority order.
Finally, we then go through each cloned display target in the paths array, and set it to the configuration that windows needs so it will make a cloned display. We also go through the modes array, and set the physical display id to the corresponding mapped physical UID we calculated earlier.
All of this results in Windows accepting the cloned display configuration as expected.
This corrects some errors with the WinLibrary and how it handles cloned displays.
Also removed the 0.5 second delay between the end of the NVIDIALibrary call, and the start of the WinLibrary one, because they do not appear to be needed based on the NVIDIALibrary testing we've been doing with NVIDIAInfo.
Also corrected some log entries and comments.
I *think* that NVIDIA Surround and AMD Eyefinity changes are so great that WinLibrary gets confused and gives up. NVIDIA Surround and AMD Eyefinity affects the windows display layout so much. This change adds a windows config refresh after the NVIDIA or AMD config is applied to make sure that the winLibrary calls are using the latest updated active config that results from the NVIDIALibrary and AMDLibrary config changes.
This version of WinLibrary improves handling of multiple display adapters to cope with multiple displays across multiple display adapters. Hopefully fixes#60 (but no guarantees yet)
Did a HUGE amount of testing with the amazing help of @domenic as part of #41, and we finally got the right configuration sorted out! This update is a reflection of the changes required.
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.
