102 lines
4.6 KiB
Markdown
102 lines
4.6 KiB
Markdown
# 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.
|