9.5.40 — Record OSD fix attempt, and the register is finally read back

9.5.40 — Record OSD fix attempt, and the register is finally read back

Follows 9.5.39. Everything from 9.5.38 and 9.5.39 is included.

---

Background: Record OSD: No was still recording the OSD

Reported from the field, on HDZero. Worth stating plainly, because it shapes what this release does and does not claim:

• The setting is plumbed correctly. Display_Osd(false) really does run, and it is the last display write on the way into video.
• The recorder has no OSD handling at all — src/record/ never sees the setting. The OSD is composited in hardware before the encoder.
• The whole mechanism is therefore one FPGA register bit: 0x84, written as 0x11 (on) or 0x01 (off).
• That code is unchanged since the initial commit in December 2022. The Goggle One FPGA payload has been replaced twice since and now ships as VA-206.

Display and recording share one composited output, so there is no software workaround — the OSD cannot be kept on your screen but out of the file except by the hardware doing it.

What is fixed

The bit is now re-asserted at record start. Display_UI_init() unconditionally forces 0x84 back to "OSD on" every time the menu or the playback page brings the UI up. Applying the setting only on source entry meant anything that re-initialised the display between entering video and hitting record left it stale for the entire clip. Display_Osd() now also runs at DVR_START, writing the value you already chose — a no-op when nothing clobbered it.

HDMI In now applies the setting at all. app_switch_to_hdmi_in() never called Display_Osd(), so on that source the toggle did nothing whatsoever.

What is instrumented

The other candidate cause cannot be settled by reading source: if an FPGA payload update changed what bit 4 means, the write is correct and simply ineffective — and nothing would ever have reported it, because the register was never read back.

So now it is. FPGA registers are readable (dm6302.c and self_test.c already do it); nobody had looked at these ones.

• Display_Osd() logs the value written and what reads back
• Record start dumps 0x80–0x8F to hwlog.txt
• OSD Probe (assignable button, from 9.5.39) dumps the block before and after each candidate value and flags a readback mismatch as DID NOT STICK

One recording with Record OSD: No now answers it. Check hwlog.txt on the SD card: if 0x84 reads 0x01 at capture time and the OSD is still in the file, the value is wrong and the probe sweep will find the right one. If it reads something else, something is clobbering it and the dump shows what.

Please report the hwlog.txt line. That is what this release is for.

Honest status

Treat Record OSD: No as not yet confirmed working. This release fixes one plausible cause and makes the other diagnosable in a single flight. It is not a verified fix, and no part of it has been hardware tested.

Also unchanged, and not fixable at the goggle: on analog, the flight controller burns its OSD into the video at the aircraft, so it arrives as picture pixels. No goggle setting can remove it. On HDZero the goggle renders the OSD itself, which is why it should be removable there.

Betaflight OSD and race-timer/lap-time OSD share the same overlay plane and the same single bit, so whatever the outcome, it applies to both — there is no per-source gating.

---

Files

File	Size (bytes)	MD5
HDZERO_GOGGLE-77-206-9.5.40.bin	9973760	f1f0a82b7d0b6c0395f2bfa29185931e
HDZERO_GOGGLE2-77-184-9.5.40.bin	12892160	809692b8ab12d5df5a4a16bde08074f3
HDZERO_BOXPRO-77-211-9.5.40.bin	9676800	3532fcea23894d00fcbb969ba78af93c

Copy the .bin for your model to the SD card root, then Menu → Firmware → Update Goggle.