Not for for the present test cycle, but ...
I was configuring a laptop (a two year old Toshiba) and during install it
queried and received DCC parameters ...
Reported as a TOS5082, 31.5-48.5 and 50-70 ...
which is NOT is the Xconfigurator monitor database ...
It concluded, and runs very nicely. Obvioully new monitors and panels will
proliferate beyond the ability of anyone to keep up to date.
RFE 1. As a rework of Xconfigurator, add a DCC query, and if a DCC return
is received, perhaps a new branch of code, using that DCC data, might be
RFE 2. Ask permission, and report the DCC data of monitors names NOT found
in the Xconfigurator list back to a email collection address at RH for
Xconfig monitor list extension, in well formed format, for automated data
collection of monitor specs. See also Bugzilla 25919
Recent versions of Xconfigurator do make efficient use of DDC. they get the
EDID, look up the monitor in the database, and use that timing info if
present. If not present, it falls back to the DDC timing info, if that
appears sane. If it appears insane (and yes, some monitors have an EDID but
report refresh rates that are totally out of whack), it then makes you choose.
The monitor EDID data sharing with Red Hat is a good idea, we'll have to
figure out how to best implement getting such data back to us.