JV4

Role: sole author · Status: on hiatus since Sep 2026 — the device layer, the measurement instrument, the system audit and the window all work on my machine; it is not ready for anyone else, for a specific reason recorded at the bottom · Scale: ~5,000 lines of Rust, 25 tests

Two things a Viper V4 Pro owner cannot do without installing Razer’s Synapse: configure the mouse, and find out what the mouse is actually doing.

JV4 does both. The second one is the interesting half, because it produces a number that no existing tool in this category reports.

---

The median is a liar, again

Every mouse utility reports the polling rate you set. That figure is a configuration value read back from the device — it is not a measurement of anything.

pollmon timestamps raw HID reports as Windows delivers them and reports the distribution of the intervals actually achieved. Viper V4 Pro on the HyperSpeed dongle, nominal 4000 Hz, 10 s of continuous movement:

Percentile	Interval	Achieved rate	vs nominal
p50	250 µs	4,003 Hz	1 period
p99	502 µs	1,990 Hz	2 periods
p99.9	1,009 µs	991 Hz	4 periods

At the median the mouse delivers exactly what it claims. At the 99th percentile one report in a hundred arrives a full period late, and at p99.9 it is four periods — a quarter of the nominal rate, in the moments that are most likely to be the ones that mattered.

A tool that prints “4000 Hz” is not wrong about the median. It is silent about the tail, and the tail is the part you feel. This is the same argument as the bufferbloat work on this site, made against a different queue.

It also makes every tuning claim falsifiable: measure, change one thing, measure again, and keep the change only if the tail actually moved.

Getting the protocol out of Razer’s own configurator

There is no published protocol for this device. I captured it by instrumenting Razer’s Synapse Web Beta — a WebHID application — while it configured my mouse, and then rebuilt the transactions in Rust.

Three things cost real time and are worth writing down:

• The device code runs in a same-origin iframe, which has its own JavaScript realm and therefore its own HIDDevice.prototype. Hooking the parent window’s prototype captures absolutely nothing, silently. The hook has to go on the iframe’s contentWindow.
• The page opens the device, transacts, then closes it. A hook installed after load stays silent until the UI performs a new device action — and switching navigation sections is not enough to trigger one. You have to actually change a value.
• Configuration does not ride the vendor usage page. 0xFF13 is the advertised vendor page, and writing the 90-byte report to it fails with ERROR_INVALID_PARAMETER. The config transport is the collection on usage page 0x000C — Consumer Control — usage 0x0001.

That last one is the reason the client enumerates the device’s collections and probes each one for a handshake rather than hardcoding an interface index. An index that is correct on my machine is not a protocol fact, and this project’s whole premise is refusing to ship the difference.

Synapse was installed but its processes were never running during any of this, and device access worked regardless. That is the evidence that a standalone replacement is actually viable rather than merely desirable.

What is verified against hardware

• Every v1 setting — DPI, polling rate, lift-off distance, sleep and low-power threshold — written and read back over HID with Synapse not running.
• Onboard persistence: a written DPI survived unplugging the dongle and plugging it back in. This is the fact the entire product shape rests on. Because the settings live on the mouse, the application can exit completely — no service, no tray icon, no background process. The thing it replaces never stops running, and that is the main complaint about it.
• Nine Windows settings inspected read-only and unprivileged by systune, each classified by what kind of claim it can actually support rather than presented as a list of tweaks to apply.

Why it is not downloadable

The wired connection is a different product ID from the wireless one, and I have only ever captured the wireless path. The device layer currently accepts both, which means on someone else’s desk the configurator could write frames to an interface nobody has ever observed responding.

That is the one way this software could damage hardware that is not mine. Fixing it is either a capture of the wired path or a refusal to open that product ID at all — and until one of those is done, shipping an installer would be indefensible. Apply-with-rollback and code signing are unstarted behind it.

The measurement half is honest, the device half is verified on exactly one mouse, and the distribution story says so out loud instead of finding out from someone else’s hardware.