mirror of
https://github.com/MCKero6423/uv-k5-v3-emulator.git
synced 2026-10-05 20:47:28 +00:00
mckero
ab84ee1fb8
The both-ends dump never printed. The value really is set: every QMP reply printed shows qom-get press '' -> qom-set F {} -> qom-get 'F' -> still 'F' after 3 s -> clear -> ''. And SET lines 0, UPD lines 0, with 3488 bytes of stderr so nothing was truncated.
A stale binary was the obvious suspect and it is not one: the built executable contains the probe's format strings (SET name=%s at 0xce16e8, UPD %s[4][3] at 0xce1310, GPIOCOLCHG at 0xce2368), while round 111's CORR block is absent as intended. So the instrumentation is compiled in, the setter is registered as that property's setter, the QMP command succeeds, the getter reads the value back -- and the setter never runs.
The only shape that fits is that the object QMP set the property on is not the object wired to the keypad matrix: the readback succeeds on whichever object was written, and keypad_update_rows, called 1.6 million times from the column lines, reads the other one. That single sentence accounts for every reading since round 105 -- the cell set and verified, the scan running at full rate, and the two never meeting.
Next: print (void *)s from keypad_set_press and from keypad_col_changed. If the pointers differ, the board creates its keypad under a name the QMP path does not resolve, and every host-side key injection in this session has been landing on a second, unwired instance.