GitLab

Detail:
  Export the EDID raw data as a file in ResourceFS. This allows the Screen Setup plugin to scan that directory to pick up the currently connected monitor, and similarly select it from !Boot.Choices.PreDesk. The EDID data can also be drag & drop copied or exported for offline analysis.
  Add SaveModeFile command. This differs in that it works on the current set, to be symmetrical with LoadModeFile which loads the current set. Also fixes issues of losing the original mode names given; NULL pointer dereference when the EDID block contains no modes (eg. VIDCDriver); and no long writes out malformed MDFs which can't be loaded into !MakeModes (this seems to be because the CreateModeFile command was based on a stale copy of EDIDDecode which fixed the same bug circa 2012).
  Query the current GraphicsV driver for the deepest colour depth for the preferred mode, rather than assuming 32bpp is always possible (eg. because of bandwidth or graphics controller constraints).
  If the configured MonitorType is EDID but no EDID could be read, or it was corrupt, substitute a safe VESA monitor to allow the kernel to select something close to MODE 28.
  Add ScreenModes_Features SWI so the Screen Setup plugin knows whether it's safe to offer EDID in its dialogues.
  Retire the ReadEDID command (no longer needed since LoadModeFile can load the exported EDID blob, or one from disc) and CreateModeFile commands (see SaveModeFile).
  Internationalise the default monitor title ("Unidentified") used when EDID doesn't contain one.
Admin:
  New file - doc/BootStates documents all possible situations, and their recovery, for both the MDF and (non-hotplug) EDID schemes.
  New file - doc/EDIDGoals states the aims of the EDID support from both a user and support perspective.

  Submission for the EDID bounty.

Version 0.61. Tagged as 'ScrModes-0_61'

Detail:
  Some cross-checking against the RISC OS Select documentation revealed that ScreenModes_ReadInfo 1 had already been claimed by ROL for the purpose of reading the monitor's supported DMPS state, causing a clash with our recently-introduced usage of reading the monitor speaker mask.
  Implement ScreenModes_ReadInfo 1 as per ROL's spec, and change the "read speaker mask" call to ScreenModes_ReadInfo 2.
  File changes:
  - c/ScrModes, hdr/ScrModes - as above
Admin:
  Tested on Raspberry Pi


Version 0.58. Tagged as 'ScrModes-0_58'

Detail:
  Makefile - Export a C version of hdr/ScrModes
  Resources/Germany/Messages, Resources/UK/Messages, h/errors - Add new error message
  cmhg/ScrModesv, hdr/ScrModes - Declare existence of ScreenModes_EnumerateAudioFormats SWI. Declare ScreenModes_ReadInfo reason codes.
  h/modex - Extend MonitorDefinition struct to allow it to store the speaker mask & audio format information that's extracted from the EDID
  c/ScrModes - Extend support for processing of CEA extension blocks. All block revisions > 0 should now be accepted, and rudimentary parsing of CEA data block collections is implemented (currently, only extracts information from audio related blocks). Add SWI ScreenModes_EnumerateAudioFormats to allow details of the supported formats to be returned in either "raw" or "friendly" forms. Add ScreenModes_ReadInfo reason code 1 to allow reading of the speaker mask (+ validity bits). Also fix *LoadModeFile to allow EDID blocks to be loaded without first having to issue *ReadEDID first (EDIDEnabled flag issue).
Admin:
  Tested on iMX6 with assorted EDID blocks
  German messages file in need of translation


Version 0.49. Tagged as 'ScrModes-0_49'