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.
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 :/
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,
