mirror of
https://github.com/MCKero6423/uv-k5-v3-emulator.git
synced 2026-10-02 11:07:31 +00:00
mckero
dbe7607720
Reverts optimistic send. The browser times the press with performance.now() and sends it once on release, so the firmware sees exactly the press that was made. Optimistic send fired a speculative tap at pointerdown plus a held press if the button was still down. It was 152 ms faster (505 vs 657 ms click-to-visible at 400 ms RTT) but it guessed, and a wrong guess sent both presses for the firmware to act on. Raising the threshold to 900 ms hid the symptom without removing the failure mode, and it also made hold-to-repeat unreachable, since the server released the key after a fixed 900 ms no matter how long you held. Measuring costs the click duration in latency and buys exactness plus real hold-to-repeat. Verified against the firmware: taps under 400 ms 120/250/390 ms -> cursor +1, submenu never opens holds from 400 ms 500/900/1500 ms -> cursor +3/+8/+15 MENU tap 120/300/390 ms -> menu opens, submenu stays shut One correction to my own expectations along the way: I first recorded the multi-step moves at 500 and 800 ms as failures. They are not. App/misc.c has key_repeat_10ms = 8, so past 400 ms the firmware auto-repeats every 80 ms, and the counts match (duration - 400) / 80. That is what a real radio does when you hold a button, so the note on FIRMWARE_HELD_MS now says not to filter it out. MIN_HOLD_MS returns as the floor for a measured press, since a very fast click can measure below the debounce window. LONG_PRESS_AFTER_MS and LONG_PRESS_MS are gone with the scheme that needed them.