Commit ac864787 by PLN (Algolia)

feat(lcxl3): a probe that asks the device instead of us guessing

Three rounds of screen fixes were hypotheses dressed as patches: the lap clock
is frozen at 0:00 on glass while our ghost ticks, and the DJF Hz readout
"refresh maybe every 1s, not smooth at all". Both point at one unproven rule —
that a field write to an ALREADY-VISIBLE display target does not repaint
without a bring-up — and the protocol offers no display readback, so the only
instrument that can settle it is PLN's eyes, asked precise questions in order.

So: a guided probe. Each step prints an instruction, sends a minimal
distinguishing sequence, and records what he saw; the run ends with a table and
a verdict naming the surviving hypothesis, plus JSON in the scratchpad so the
answers outlive the session. --dry-run prints every byte with the hypothesis it
tests, so the whole thing is reviewable without hardware.

It distinguishes: bring-up NONE/AFTER/BEFORE/RECONFIG on the stationary target;
the same on the temporary target plus a 20/10/5-per-second rate ladder (which
directly decides the DJF smoothness fix); whether per-control targets can be
driven while untouched; which auto bit actually summons; and an arrangement
census with a SENTINEL, so an arrangement the firmware IGNORES reads as "still
the sentinel" instead of masquerading as a real layout — without that, "ignored"
and "renders like the previous one" are the same observation and the census
would invent arrangements that do not exist.

Two things it found by reading our code, before touching the device. The
targets showing both symptoms are on arrangement 2, not the 4 we describe in
our own notes (4 is only label_control's default). And CFG_BRING_UP = 0x7F is
arithmetically ARR_TRIGGER | AUTO_TOUCH | AUTO_CHANGE, so every bring-up may
RE-ARM the auto-display bits we deliberately clear on the three DJF knobs —
which would explain, mechanically, why the firmware's number keeps reappearing
over "HPF 3.4kHz !!". That became its own probe step.

Safety, since the rig is live: display and config SysEx only, enforced by an AST
check that there are zero cc/note/rgb/feature call sites plus raisers installed
over those methods at open time; it refuses to run while the driver is up
(printing the pid, the kill, and the restart line); and it restores the
arrangement the driver expects from a finally block.

NOT YET RUN ON HARDWARE — committed so the work is not parked in a scratchpad.
parent 15c2c86a
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment