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,
