Properly apply Bypass video mode from custom preset

[nyanpasu64]

Fixes:

• Loading and saving custom preset used to produce a preset entry showing the output resolution as Custom, rather than the actual output resolution. This meant that loading and saving a preset was not a no-op.
  • This PR fixes it to save the output resolution for your current input resolution. This makes loading and saving a preset a no-op, as long as you saved it in the same input resolution as the last time you saved.
  • Deferred to a later PR because you can't read hardware (which yields) in a HTTP callback (which must not yield), requiring more invasive code changes.
• Previously loading a custom preset containing Bypass would fail to load properly, if you hadn't already loaded Bypass in the same console power-on.
  • This PR properly reapplies Bypass when reloading custom presets which pass-through sync at the current input resolution.
• Add enum PresetID (incomplete).
• Attempt to better document how userOptions's PresetPreference controls output resolution and runTimeOptions's PresetID.

draft. applies on top of PR #415 (not yet merged), so the github diff view includes irrelevant changes. will be rebased once that's merged.

• [x] if you're comfortable, I could start pushing branches directly to this upstream repo, then I can "stack" PRs on top of each other.

todo:

• [x] merge #415
• [x] combine "Rename OutputMode back to PresetPreference" comment rewrites with commit "Add enum PresetID for derived state"
• [x] add more descriptive multi-line commit messages
• [x] test more

Fixes #416.

[nyanpasu64]

saving presets can lead to flash write corruption:

corruption is usually (possibly always?) seen after the ESP hangs and the hardware watchdog reboots it. sometimes the hardware watchdog reboots the ESP but the flash appears intact afterwards.

was it caused by reading chip registers while performing flash operations? no, we call GBS::GBS_PRESET_ID::read() before SPIFFS.open(SLOTS_FILE, "w").

[nyanpasu64]

read corruption after saving a preset:

refreshing the page fixes the contents read from the slots file. usually the web UI automatically reloads the slot list with the correct list a split-second later. this time it didn't, so I was able to take a screenshot.

I was able to reproduce flash corruption on master c4babdd49da0a7d299b3e246d89fb9bb9a5efaaa.

I now think flash corruption is not caused by the changes made in this PR, but instead caused by https://github.com/me-no-dev/ESPAsyncWebServer/issues/204:

the corruption problems seem to have disappeared after I moved the web pages in the firmware image (which is a nice feature of EspAsyncWebServer). In other words, the webserver is not using SPIFFS for static web content anymore. The flash file system is only accessed by the "server.on" functions to read log data and output it in JSON. The same data is also accessed by the logging functions in the main loop, but concurrent access is avoided by means of synchronisation flags. This was not possible when the web pages were loaded from SPIFFS, because the webserver accessed them asynchronously and there was no way to synchronise access with flags.

sounds like it's illegal to even access different SPIFFS files concurrently, if you don't manually lock the filesystem. that would explain the separate write and read corruption modes I've observed.

options:

• burn the code down
• "synchronous webserver" (a different library altogether?)
• rewrite the webserver to properly lock the filesystem
• make the esp filesystem multithreaded
• use a different filesystem

[nyanpasu64]

marking as draft. you can't yield in a http callback. and reading registers over i2c yields.

fuck AsyncWebServer.

[nyanpasu64]

apparently Bypass (both directly applied and from a preset) generates EMI that interferes with WiFi channel 11 communications. This is unrelated to this PR, but makes testing trickier.