Corsair M65 RGB Ultra Input Lag Test

Corsair M65 RGB Ultra Input Lag Test: Click Latency Check

An aluminium chassis and adjustable weight system make the M65 RGB Ultra a stable FPS-aim mouse rather than an ultra-light ergonomic pick. It uses Corsair Quickstrike optical switches with zero gap between the primary buttons and their optical switches.¹ Use this tool to measure click latency and check all button responses.

Specifications¹

Polling rate and connectivity

By default, the M65 RGB Ultra connects via USB-A and supports selectable polling rates including 1000 Hz.² Polling rate changes require Corsair iCUE, but the mouse stores the selected rate in onboard memory and applies it without Corsair iCUE running after the change. At 1000 Hz, click and movement events arrive at 1 ms intervals. The aluminium chassis and adjustable weight system change physical feel but have no effect on USB timing. Your Hz chart should read close to 1000 on any rear motherboard USB-A port.

Onboard polling settings after iCUE closes

Onboard memory is useful when you want iCUE closed during testing. Set the polling rate once, disconnect and reconnect the mouse, then run the same movement sample again. If the Hz chart stays close to 1000 after the software exits, the mouse is applying the profile correctly and the browser test is measuring the configured hardware path rather than a software-driven exception.

If your reading sits below 1000 Hz despite using a rear USB-A port, check USB selective suspend and other Windows USB power-management settings before assuming a mouse fault.³ The M65 stores its polling rate in onboard memory and applies it immediately on connection, making a low reading after confirming 1000 Hz in iCUE a system configuration problem rather than a mouse issue. Open Device Manager, expand USB Root Hub under Universal Serial Bus Controllers, open Properties, select Power Management, and uncheck the option that allows the computer to turn off the device to save power before retesting.

Switch technology and click latency

Corsair Quickstrike is an optical switch design. The button lever pre-tensions so the optical beam fires at the first point of physical contact rather than at the bottom of travel, and the primary buttons sit with zero gap above their optical switches.⁴ Eliminating pre-travel reduces the gap between finger intention and register event. The absence of mechanical contacts also means the Quickstrike switch should not develop the contact-bounce double-click failure common on aged mechanical switches.⁵ Consequently, click latency in this test typically sits between 1 and 3 ms, lower than standard mechanical mice and comparable to other optical designs.⁶

Running the test without iCUE open reveals the baseline latency the switch hardware produces without software scheduling overhead. Comparing with iCUE running using 20 clicks per state can show whether your software configuration contributes meaningfully to total click latency on your system. If the iCUE-closed average is consistently lower, the difference quantifies how much the Corsair software layer adds to your specific Windows installation, which is useful information when deciding whether to keep iCUE running during competitive play or to close it and accept the tradeoff of losing real-time DPI-shift and macro functionality.

Testing this mouse

Connect the M65 to a rear USB-A port and run the test without iCUE open to see the baseline switch and USB path. Your Hz reading should stay near 1000 with minimal variance. If you see unexpected double events, verify your iCUE button assignment configuration before interpreting the test output as a hardware issue.

Sniper button behavior in the browser event log

The sniper button on the M65 uses a DPI-shift firmware mechanism that does not send a standard mouse button event to the browser.⁴ Pressing the sniper button changes DPI in onboard memory while held and releases the change on release. The click latency log does not show a sniper button entry; you may observe the movement Hz chart shift briefly as the DPI change alters how sensor displacement scales, but the log entry count stays unchanged. All five primary and side buttons that do generate mouse events appear in the log correctly and can be verified in sequence.

Why the sniper button behaves differently in the log

The sniper button is still useful, but it changes DPI rather than emitting a standard browser mouse button event. Pressing the sniper button shifts the sensor to a lower DPI profile while held, which can cause the Hz chart to briefly fluctuate as the cursor scaling changes mid-movement. Treat it as a DPI-shift control and verify the primary, right, middle, and side buttons separately in the click latency log of this M65 sniper button event gap. This prevents a false hardware diagnosis when one button intentionally operates outside the browser event model, and it also explains why the movement chart may show a brief anomaly when the sniper button is pressed during a polling rate test.