mirror of
https://github.com/MCKero6423/uv-k5-v3-emulator.git
synced 2026-10-07 05:27:21 +00:00
mckero
fcff3fc971
The probe round 97 asked for is in the model now, env-gated by UVK5_KEYPAD_PROBE and printing every 20000 keypad_update_rows() calls: the count, which columns are high, and which cells are held. Resident loop: colhigh=0x1a, one column pulled low. Overlay app: colhigh=0x1e, every real column high, with pressed=0x01000 -- column 3 row 0 -- genuinely set by the injection. 1.68 million calls in one run, so the model is being asked. A row goes low only when a held key sits on a column that is currently pulled low. Columns at rest, key in the model, no row ever low: the firmware is not scanning, and KEYBOARD_Poll's five-column loop body is not executing while an overlay app owns the foreground. That loop has exactly one way out before it runs -- the serial-injection branch, which returns only when gKeyFromSerial is set -- and the overlay loader's app_get_key calls K5VIEWER_ParseInput immediately before polling, the one thing the overlay path does that the resident loop does not do in the same place. Operational lesson paid for here: one probe line per 200 calls produced 450 KB of stderr and cut off the QMP client mid-test. Draining stderr is what made the flood survivable, but a probe's rate must be chosen for the reader as well as the thing measured.