mirror of
https://github.com/MCKero6423/uv-k5-v3-emulator.git
synced 2026-10-02 11:07:31 +00:00
Two changes, both aimed only at latency, since that is what the link makes expensive. 1. Send on pointerdown instead of pointerup. Waiting for release left the network idle for the entire click. The duration is unknown at that moment, so the speculative request asks for a short press; holding past LONG_PRESS_AFTER_MS sends a second, deliberately long press, which is how held events stay reachable. 2. TAP_MS 200 -> 60 ms. The server blocks for hold_ms before replying, so this is latency the user pays directly. 200 ms was a guess that gave back most of what change 1 saved. The 60 ms is measured, and the sample size mattered: at 4 trials per value 30 ms looked reliable, but at 12 trials 20 ms registered only 5/12 while 30 ms was 12/12. The nominal 20 ms debounce is not sufficient alone because KEYBOARD_Poll samples each column 8 times wanting 2 matching reads. 60 ms is double the proven floor. Click-to-visible at 400 ms RTT, where one round trip is an unavoidable 400 ms: original (2 requests, on release) 2525 ms (+2125 over the floor) one request, on release 657 ms (+257) current (1 request, on press) 505 ms (+105) Long press still works: a 60 ms press opens the menu (gScreenToDisplay 0 -> 1) while a 900 ms press is treated as held and correctly does not, so the firmware still distinguishes them. Also drops MIN_HOLD_MS, now dead: the browser no longer measures press duration, so there is no measurement to clamp. Its test asserted only that the string appeared, which would have kept passing over dead code.