Files
uv-k5-v3-emulator/tools
mckero 20e7577257 Cut key latency: fire at pointerdown and shorten the tap
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.
2026-08-28 09:56:04 +01:00
..