vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: MFD panels never appeared with the HARDWARE RIO (PadRIO coupling)

Browse Source 
Nick ran the cab with the real board and the mission came up on the main view
with every MFD dark -- and not one [glasswin] line in the log.

BTGlassPanels_Create() was called only from the END OF THE PadRIO CONSTRUCTOR.
The panels began as the frames around the on-screen RIO button banks, so "the
buttons ride the device" was reasonable then; it is backwards on a real cab.
L4CONTROLS=RIO:COM1 means PadRIO is never constructed, so the MFD windows were
never created -- silently, since nothing is wrong from the display layer's
point of view.

The panels are a DISPLAY concern.  Creation moves to LBE4ControlsManager,
after the L4CONTROLS parse where every device branch converges, and a
symmetric BTGlassPanels_Destroy() goes in its destructor: ~PadRIO tore them
down, ~RIO knows nothing about them, and windows outliving the surfaces they
blit would crash on the next mission cycle.  Both calls are idempotent
(Create returns on gWinCount != 0), so the proven PadRIO path is unchanged
and simply arrives first.  Both guarded by BT_GLASS -- L4GLASSWIN is only in
the build when the gate is on.

Verified on the cart: hardware RIO up AND all three surfaces on their intended
displays in the same run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rw7No5wLTpkaUgA3ANbtZZ
This commit is contained in:
Joe DiPrima
2026-08-06 19:05:04 -05:00
co-authored by Claude Opus 5
parent 6fcff95010
commit d213c980a9
2 changed files with 49 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/pod-hardware.md
+11
View File
@@ -371,6 +371,17 @@ input device changes, which is what the glass/PadRIO seam was built for. Do NOT
pedals `0..470`). A mismatch shows up as drift or short travel, not as an error.
- The boot banner names the resolved device — `GLASS (hardware RIO; plasma off [L4PLASMA])`. It
used to hardcode "PadRIO", which is a lie on a wired cab and exactly the line you read to check.
- ⚠ **THE COUPLING BUG this exposed (fixed 2026-08-06) [T2].** `BTGlassPanels_Create()` was called
ONLY from the end of the **PadRIO constructor** — the panels began life as the frames around the
on-screen RIO button banks, so "the buttons ride the device". Selecting the hardware RIO means
PadRIO is never constructed, so **every MFD window silently failed to appear**: the mission came
up on the main view with all the pod glass dark, and not one `[glasswin]` line in the log. The
MFD panels are a DISPLAY concern, so creation moved to `LBE4ControlsManager` after the
`L4CONTROLS` parse, where every device branch converges — plus a symmetric `BTGlassPanels_Destroy()`
in its destructor, because `~PadRIO` tore them down and `~RIO` knows nothing about them (windows
outliving the surfaces they blit would crash on the next mission cycle). Both calls are
idempotent (`Create` returns on `gWinCount != 0`), so the PadRIO path is unchanged and simply
arrives first.
**Working on the cart, remotely.** SSH over Tailscale lands in **session 0**, which has a dummy
"WinDisc" display and CANNOT see or enumerate session 1's windows — GUI work must go through