POD MFD bring-up: BT_POD_SURFACES bare-panel mode + placement receipts + probe

Nick's crash cart is the first shot at driving the real MFD panels, so the
pieces the cab needs that the desktop glass path lacked:

- BT_POD_SURFACES=1 (L4GLASSWIN): crop every display window to its SURFACE
  (MFDs exactly 640x480, radar 480x640 portrait), drop the on-screen RIO
  button banks -- the cab's buttons are PHYSICAL, so drawing fake ones onto a
  real panel is exactly wrong -- go frameless, and skip the Flight Controls
  pad entirely (6 windows, not 7).  Per-window ",bare" in glass_layout.cfg
  for mixed rigs (idempotent with the global mode).
- Placement receipts: each window logs which PHYSICAL monitor it landed on
  ("[glasswin] 'Heat MFD' surface=Heat at X,Y 640x480 bare -> monitor
  \.\DISPLAYn (...)").  Nobody can see 7 surfaces at once on a cab, and over
  Chrome Remote Desktop you cannot see the panels at all -- the log is the
  only confirmation the map is right.
- tools/podprobe.ps1: run-on-the-pod topology probe (no install/admin) --
  GPUs, every monitor's virtual-desktop rect, EDID make/model, serial ports
  (the RIO board), session type, plus a PROPOSED glass_layout.cfg assigning
  the six surfaces to the non-primary monitors.  Self-tested here (correctly
  reports a single-monitor laptop and declines to map).

Local verify: 5 MFDs at 640x480 bare + portrait radar + Flight Controls
dropped, receipts printed.  KB: pod-hardware §MFD PANELS ON REAL HARDWARE
(incl. WHY the 1995 path is not the route -- NVIDIA Horizontal Span is gone
from post-XP drivers and per-adapter exclusive fullscreen is fragile over a
remote session) + glass-cockpit env table.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/glass-cockpit.md

@@ -73,6 +73,7 @@ that one answer. Precedence, highest first:
 | Env | Layout | Buttons live in |
 |---|---|---|
 | `BT_GLASS_PANELS`≠0 | per-display cockpit windows (the "exploded" view, `L4GLASSWIN`) | each display's own window |
+| `BT_POD_SURFACES`=1 | **POD MODE** (2026-08-06): crop each panel window to its SURFACE (MFD 640×480, radar 480×640), drop the on-screen button banks + the Flight Controls pad, frameless. For REAL pod glass, where the buttons are physical — see [[pod-hardware]] §MFD PANELS. Per-window: `,bare` in `glass_layout.cfg`. | 6 bare surfaces |
 | `BT_DEV_GAUGES_WINDOW` | the legacy separate MFD window | the single combined pad panel |
 | `BT_DEV_GAUGES_DOCK` | the docked bottom gauge strip | the single combined pad panel |
 | `BT_COCKPIT=0` | ...also the docked strip (the documented opt-out) | the single combined pad panel |

context/pod-hardware.md

@@ -184,6 +184,44 @@ All cockpit surfaces are bit-plane MASKS over ONE shared `SVGA16` pixelBuffer: `
 byte; `Heat`=0x4000, `Mfd2`=0x0400, `Comm`=0x8000, `Mfd1`=0x0100, `Mfd3`=0x1000; `Eng1-3` =
 engineering-mode alt planes; `overlay`=0x00C0 (shares the sec surface). See [[gauges-hud]]. [T2]
 
+## MFD PANELS ON REAL HARDWARE — the bring-up path (2026-08-06) [T2 local / T4 on-pod]
+Nick's crash cart (pod hardware + Chrome Remote Desktop on a burner account) is the first chance
+to drive the real panels. **The 1995 display path is NOT the way in.** That rig spanned the five
+MFDs as ONE 1280×480 surface via **NVIDIA Horizontal Span, which every driver after XP dropped**;
+`SVGA16::BuildWindows` also wants an exclusive-fullscreen D3D device per adapter, which is
+fragile on modern drivers and over a remote session. Both are still in-tree and still the
+authentic reference — they are just not the bring-up route.
+
+**The route is the glass per-display windows** ([[glass-cockpit]]): one window per surface, which
+maps 1:1 onto one physical panel per MFD, needs no special driver, and is already field-proven on
+desktops. Two pieces were added for the cab:
+- **`BT_POD_SURFACES=1` (pod surface mode, L4GLASSWIN)** — crops every window to its SURFACE
+  (MFDs exactly 640×480, radar 480×640 portrait), drops the on-screen RIO button banks (the cab's
+  buttons are PHYSICAL — drawing fake ones over a real panel is precisely wrong), goes frameless,
+  and does not create the Flight Controls pad at all (6 windows, not 7). Per-window equivalent:
+  append `,bare` to a line in `glass_layout.cfg` (mixed rigs).
+- **Placement receipts** — every window logs `[glasswin] '<title>' surface=<port> at X,Y WxH
+  bare -> monitor \.\DISPLAYn (origin WxH, PRIMARY)`. On a cab nobody can see seven surfaces at
+  once, and over CRD you cannot see the panels at all: the log IS the confirmation that a picture
+  landed on the right glass.
+
+**Runbook** (`tools/podprobe.ps1`, PowerShell, no install/admin — run it ON the pod PC):
+1. Probe: GPUs, every monitor's virtual-desktop rect, EDID make/model (identifies the original
+   panels), serial ports (the RIO board), session type, and a PROPOSED `glass_layout.cfg` that
+   assigns the six surfaces to the non-primary monitors top-to-bottom/left-to-right, centred.
+2. Drop the cfg in the game's working directory; run with `BT_GLASS=1 BT_GLASS_PANELS=1
+   BT_POD_SURFACES=1 BT_GLASS_LAYOUT=load` (`=save` to persist drags instead).
+3. Read the receipts; re-assign titles to monitors in the cfg until each picture is on its panel.
+Surface→panel roles: Heat MFD = upper left (coolant), Engineering = upper centre, Comm MFD =
+upper right (hot box), Left/Right Weapons = lower left/right, Secondary/Radar = the secondary
+screen (portrait). Main 3D view stays the game's own window on the main-view monitor.
+
+**Known constraints / open on-pod questions:** whether the panels are attached to this PC at all
+(the probe answers it); whether Windows offers a 640×480 mode on them (if not, the surface renders
+at native size CENTRED, not scaled — a scale-to-fit option is the obvious follow-up); whether
+Chrome Remote Desktop holds the CONSOLE session (it should — an RDP session would get a virtual
+display and light nothing); and the RIO serial input, which is a separate task from the displays.
+
 ## The 1995 player manual — alignment audit (2026-07-18) [T1, primary source]
 `reference/manual/Tesla40_BT_manual.pdf` (34pp, from Nick). CONFIRMS the reconstruction on
 every checked control behavior: