traces

docs/pt2-button-report-bench-plan.md

@@ -0,0 +1,101 @@
+# PT2 Button Report Bench Plan
+
+Date: 2026-05-26
+
+## Question
+
+After the SHUTTER ON/OFF test exposed queued frames:
+
+```text
+02 01 0F 80 00 D6
+01 01 0F 80 00 D5
+```
+
+the next bench question is whether other buttons share the same common queue-service gate, or whether each button/selector needs its own feature gate.
+
+## Current ROM Model
+
+The known button ROM trace says many physical buttons share this front-door path:
+
+```text
+panel byte snapshot -> shadow byte -> dirty bit -> loc_1C0E jump table -> handler -> loc_3E54 report builder
+```
+
+CALL and CAM POWER use this path, and SHUTTER ON/OFF now appears to use it too once the CCU side services the queued report stream.
+
+The handlers diverge after the front door. Some directly build reports. Others depend on session/menu/feature state, especially secondary-table `E400` bits.
+
+## Test Method
+
+Run a no-button baseline first:
+
+```powershell
+.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\button-report-common-gate-baseline.json --parity E --quiet-console --log captures\button-common-baseline.txt --result-json captures\button-common-baseline-result.json
+```
+
+Then run one physical button candidate through the same common gate:
+
+```powershell
+.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\button-report-common-gate-press.json --parity E --quiet-console --log captures\button-common-SHORTNAME.txt --result-json captures\button-common-SHORTNAME-result.json
+```
+
+Compare the result JSONs:
+
+```powershell
+.\.venv\Scripts\python.exe scripts\serial_scenario_compare.py captures\button-common-baseline-result.json captures\button-common-SHORTNAME-result.json --show-labels
+```
+
+If the candidate run has extra ACK-target frames, decode their selector/value. That suggests the button shares the common queue-service gate.
+
+## Broad-Gate Fallback
+
+If common-gate produces no extra selector for a button that should plausibly report, try the broader secondary-gate run:
+
+```powershell
+.\.venv\Scripts\python.exe scripts\serial_scenario.py scenarios\button-report-broad-gates-press.json --parity E --quiet-console --log captures\button-broad-SHORTNAME.txt --result-json captures\button-broad-SHORTNAME-result.json
+```
+
+Compare it against the same baseline:
+
+```powershell
+.\.venv\Scripts\python.exe scripts\serial_scenario_compare.py captures\button-common-baseline-result.json captures\button-broad-SHORTNAME-result.json --show-labels
+```
+
+If a button only emits in the broad-gate run, it likely needs a selector-specific feature/report gate rather than only the common queue-service gate.
+
+## Practical Candidate Order
+
+Start with known or visually obvious controls:
+
+- SHUTTER ON/OFF: positive control, should reproduce selector `0x008F` value `0x8000`.
+- CAM POWER: known direct selector `0x0007`, useful sanity check.
+- CALL: known direct selector `0x0015`, but it can emit outside active state so treat it as a control.
+- KNEE AUTO, DETAIL, BARS, WHITE BALANCE, BLACK/FLARE, and OTHER: useful unknowns because prior display/lamp tests suggest nearby ROM handlers and selector state.
+
+Run one physical button per capture. The queue emits background reports, so button identity is much easier to recover by comparing against the no-button baseline than by reading one log in isolation.
+
+## First Common-Gate Results
+
+The first common-gate bench set compared each one-button run against `button-common-baseline`.
+
+Positive results:
+
+| Button | Extra queued report(s) | Current meaning |
+| --- | --- | --- |
+| BARS | `01/02 00 17 80 00`, `01/02 00 18 80 00` | BARS shares the common queue-service gate. This matches the ROM handler that emits selectors `0x0017` and `0x0018`. |
+| IRIS AUTO | `01/02 01 1A 08 00` | IRIS AUTO shares the common queue-service gate. This matches selector `0x009A` in the ROM button trace. |
+
+No extra ACK-target frames were found in these common-gate runs:
+
+- STANDARD
+- MASTER
+- SLAVE
+- KNEE AUTO
+- BLACK/FLARE FLARE
+- OTHERS
+
+Interpretation: at least some local controls use the same queue-service gate as SHUTTER ON/OFF, but not every physical button emits through this simple state. The silent candidates may need a different secondary/menu/session gate, may be display-only in this mode, or may not have been captured as a single edge event.
+
+OTHERS is now treated separately in `pt2-menu-state-machine.md` because the ROM evidence points to a local menu/display key rather than a simple report button.
+
+Note: the result JSONs preserved the per-button summaries, but the test log path was reused as `button-common-SHORTNAME.txt` for the candidate runs. For future runs, replace `SHORTNAME` in both `--log` and `--result-json` so the full timeline is preserved per button.