Restore explicit resolutionType_e wire values for DJI WTFOS OSD

[sensei-hacker]

Summary

Fixes a 9.1.0 regression where the DJI WTFOS (Caddx Vista/DJI Air Unit + DJI Goggles) MSP DisplayPort OSD renders globally shifted relative to the video frame.

Root Cause

Commit 7ec7f0d (PR #10540, "Remove HD_3016 from resolutionType_e enum") removed HD_3016 from the middle of the resolutionType_e enum, which had no explicit values. That shifted every later member's implicit ordinal down by one: HD_6022 (the DJI WTFOS 60x22 mode) went from wire value 3 to wire value 2.

currentOsdMode is sent as a raw byte in the MSP_DP_OPTIONS MSP DisplayPort subcommand. WTFOS goggles/VTX firmware hardcodes wire value 3 for its 60x22 mode, so it now misinterprets the byte INAV sends, producing the reported canvas misalignment.

Changes

• src/main/io/displayport_msp_osd.c: give resolutionType_e explicit values, restoring HD_6022 = 3 (and HD_5320 = 4, HD_3016 = 2 as an intentional unused placeholder to hold the ordinal). Added a comment noting these are wire-protocol constants that must stay fixed.

Testing

• Built SITL successfully in a clean checkout with this change (no warnings/errors for this file or elsewhere).
• Verified via source inspection that no other code (in this file, or elsewhere in src/main) depends on the enum's ordinal values via arithmetic, comparison, or indexing — currentOsdMode is only ever assigned by name and serialized as a raw byte, so this change is safe.
• Confirmed inav-configurator has no hardcoded copy of these wire values to keep in sync.
• Not yet hardware-tested against real WTFOS goggles/VTX — I don't have that hardware. Marking Testing Required; would appreciate confirmation from a WTFOS/Vista user (e.g. from the issue thread) that OSD alignment is restored to 9.0.1/8.0.1 behavior.

Code Review

Reviewed with the project's automated code-review process — no critical or important issues found.

Related Issues

Fixes #11764

Credit to the community members who diagnosed the root cause on the issue thread (b14ckyy, daijoubu).

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Fix DJI WTFOS OSD shift by pinning MSP DisplayPort resolution wire values

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Restore stable MSP DisplayPort currentOsdMode byte values for DJI WTFOS 60x22 mode.
• Prevent enum edits from renumbering wire-protocol ordinals relied on by third-party firmware.
• Document the enum as protocol constants to avoid future regressions.

Diagram

graph TD
  A["INAV MSP OSD (displayport_msp_osd.c)"] --> B["resolutionType_e (explicit ordinals)"] --> C["currentOsdMode byte"] --> D["MSP_DP_OPTIONS"] --> E{{"DJI/Vista + WTFOS firmware"}} --> F["OSD canvas alignment"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Replace enum with explicit protocol constants (#defines/const uint8_t)

• ➕ Makes it harder for future refactors to accidentally rely on enum ordering
• ➕ Clarifies that values are protocol bytes, not a general-purpose enum
• ➖ Reduces type safety/readability at assignment sites (vs using enum names)
• ➖ Would be a broader style change than needed for a targeted regression fix

2. Add compile-time guards (static_assert) for expected ordinals

• ➕ Fails the build if ordinals change again, preventing repeat regressions
• ➕ Keeps the current enum-based API intact
• ➖ Requires consistent static assert support/headers across targets/toolchains
• ➖ Still needs explicit values (or the asserts will fail after renumbering)

3. Protocol versioning/negotiation for DisplayPort options

• ➕ More robust long-term against mismatched firmware expectations
• ➕ Could support future expansion without relying on fixed ordinals
• ➖ Overkill for this issue; requires changes on both INAV and goggle/VTX firmware
• ➖ Hard/impossible to deploy for third-party firmware that is already hardcoded

Recommendation: The PR’s approach—assigning explicit numeric values and documenting them as wire-protocol constants—is the most appropriate minimal fix for an interoperability regression. If you want extra regression-proofing, consider a follow-up that adds compile-time assertions for the critical values (e.g., HD_6022 == 3) where toolchain support allows.

Files changed (1) +8 / -4

Bug fix (1) +8 / -4

displayport_msp_osd.cPin DisplayPort resolution ordinals to restore DJI WTFOS 60x22 mode +8/-4

Pin DisplayPort resolution ordinals to restore DJI WTFOS 60x22 mode

• Adds a warning comment that 'resolutionType_e' values are wire-protocol constants for MSP DisplayPort options. Assigns explicit ordinals (including an unused placeholder) so the DJI WTFOS 60x22 mode remains wire value 3 and won’t be renumbered by future enum edits.

src/main/io/displayport_msp_osd.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Stale enum protocol docs ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The PR changes wire values of resolutionType_e (e.g., HD_6022 becomes 3 and HD_5320 becomes 4,
adding HD_3016=2), but the committed MSP enum reference docs still list the old ordinals. This
leaves the repository’s protocol documentation inconsistent with the firmware, risking
mis-implementation by tooling/third parties relying on these references.

Code

src/main/io/displayport_msp_osd.c[R70-72]

+    HD_3016 = 2,       // unused by INAV; reserved to hold hdzero's canonical ordinal 2
+    HD_6022 = 3,       // DJI wtfos 60x22 grid
+    HD_5320 = 4        // Avatar and BetaflightHD

Evidence

The firmware now assigns explicit ordinals (HD_6022=3, HD_5320=4, with HD_3016=2 inserted),
but the repository’s enum reference JSON/markdown still documents the previous sequence
(HD_6022=2, HD_5320=3) and omits HD_3016, so the committed protocol docs no longer match the
code.

src/main/io/displayport_msp_osd.c[64-73]
docs/development/msp/inav_enums.json[3300-3306]
docs/development/msp/inav_enums_ref.md[4824-4834]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`resolutionType_e` is a wire-protocol enum (sent as a raw byte via `MSP_DP_OPTIONS`). This PR updates its explicit values, but the committed enum reference artifacts under `docs/development/msp/` still document the old ordinals, causing protocol documentation drift.
### Issue Context
The repo contains auto-generated enum reference files (`inav_enums.json`, `inav_enums_ref.md`) produced by `docs/development/msp/gen_docs.sh` / `gen_enum_md.py`. These should reflect the updated `resolutionType_e` members and values (including the newly reintroduced `HD_3016=2`).
### Fix Focus Areas
- src/main/io/displayport_msp_osd.c[64-73]
- docs/development/msp/inav_enums.json[3300-3306]
- docs/development/msp/inav_enums_ref.md[4824-4834]
### What to change
- Regenerate/update `docs/development/msp/inav_enums.json` and `docs/development/msp/inav_enums_ref.md` so `resolutionType_e` matches the new wire values:
- `SD_3016 = 0`
- `HD_5018 = 1`
- `HD_3016 = 2`
- `HD_6022 = 3`
- `HD_5320 = 4`
- Prefer running the documented generator (`docs/development/msp/gen_docs.sh`) and committing the updated artifacts, rather than hand-editing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each action level your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

Test firmware build ready — commit 48f7fe6

Download firmware for PR #11788

244 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.