4.6 KiB
PT2 Button Report Bench Plan
Date: 2026-05-26
Question
After the SHUTTER ON/OFF test exposed queued frames:
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:
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:
.\.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:
.\.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:
.\.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:
.\.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:
.\.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
0x008Fvalue0x8000. - 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.