# 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.
