Rapid trigger is a firmware algorithm, not a switch spec

A "rapid-trigger switch" gets talked about as though it names a category, the way "clicky switch" or "silent switch" does. It doesn't. Every switch shipping under a rapid-trigger banner is electrically identical to the same lineage's ordinary variant sitting next to it in the catalog — same magnet, same Hall sensor, same continuous voltage curve. How Hall-effect switches actually sense a keypress and how optical switches read a keystroke both cover that sensor half of the story: an analog reading of travel distance, sampled by a controller instead of a contact snapping shut. Rapid trigger is what a firmware does with that reading once it has it. It's a decision loop running on the controller, not a component sitting under the keycap — and the decision it makes on every poll is more specific, and more constrained, than the marketing copy lets on.

Why a contact closure can't run this loop at all

An MX-lineage switch gives its controller exactly one bit of information: contact closed, or not. The leaf snaps against the terminal at a fixed point in the stem's travel — the actuation point cut into the housing — and the controller's only job is to watch for that transition and debounce it, waiting a few milliseconds to be sure the reading has settled before trusting the new state. Release works the same way in reverse: the leaf springs back open at a fixed point, usually a little shallower than the actuation point, and the controller waits again. Every stage of that pipeline assumes the input is binary. There's no distance value to poll, no curve to sample, no travel position to compare against anything — the switch has already collapsed the entire stroke down to a single edge before the controller ever sees it.

Rapid trigger needs the opposite: a value that keeps updating across the whole stroke, not a single edge. That's the reason the feature is confined to Hall-effect and optical switches and has never shipped on a contact-closure board at any price. It isn't that nobody has tried building it for MX; it's that the sensor a rapid-trigger firmware needs to poll doesn't exist inside an MX switch to begin with. The feature lives entirely downstream of the sensing architecture — which also explains why a Hall-effect switch with rapid trigger turned off behaves close to identically to an MX switch. The firmware is simply choosing not to use the extra information it has available.

The loop: tracking the peak, not a fixed point

On a rapid-trigger board, the controller samples every key's travel distance continuously — on the order of a thousand times a second on a wired connection, faster on boards that market their polling rate as a headline spec. Wooting's own description ↗ of the feature is the cleanest one available: it works by "dynamically activating and deactivating the key based on travel distance instead of a fixed point in the key travel."

For each key, the firmware keeps exactly one extra piece of state beyond the current position: the deepest point that key has reached since it last registered a release — the running peak of the current stroke. Every poll runs the same three-step comparison. First: has the current reading gone deeper than the stored peak? If so, update the peak. Second: has the current reading risen back up from that peak by more than a configured distance — the reset delta? If so, emit a release and clear the peak. Third: if the key isn't currently registered as pressed, has the reading crossed the ordinary actuation threshold on the way down? If so, emit a press and start tracking a fresh peak. None of those three questions has an answer written into the switch. All three are computed fresh, every poll, against a threshold the firmware owns.

Reset distance is the whole feature

That third question — has the key come up far enough from its peak to count as released — is rapid trigger's entire value proposition, and it's usually exposed to the user as a single number: sensitivity. Per Wooting's own setup guide ↗, the sensitivity setting is literally "the distance needed to de-press a key" — set it higher and a key resets after a smaller lift; set it lower and the key has to travel back up further before the firmware calls it released. Wooting's documentation states sensitivity can be set as fine as 0.1mm, meaning a key held near its peak needs to rise barely a tenth of a millimetre before it's eligible to fire again.

The consequence that makes rapid trigger useful in games, rather than just a curiosity, is what happens when a finger doesn't fully lift. On a fixed-actuation switch, a partial release that doesn't cross back past the actuation point never registers at all — the switch is still "pressed" from the controller's point of view no matter how far up the stem travels, right up until it clears that one committed depth. On a rapid-trigger switch, the same partial lift clears the reset delta long before the stem gets anywhere near the top of the stroke, the key releases, and a re-press a fraction of a millimetre later re-actuates immediately. Per the same guide, a player "can repeat a key press mid motion without needing to surpass a fixed reset or actuation point for rapid presses." The travel a finger has to cover to fire twice shrinks from the switch's full reset-to-actuation distance down to whatever delta the firmware is configured to accept — millimetres of required motion collapse to tenths of a millimetre. Some boards split that behavior into two independent sliders, one for the downstroke actuation threshold and one for the upstroke reset distance, so a builder can tune re-press speed and accidental-release resistance separately instead of trading one against the other with a single number.

The tradeoff: an analog signal has a noise floor

None of this is free, and the cost shows up exactly where the feature is most aggressive. A Hall-effect sensor's output is continuous, which means there's no threshold below which small motion simply doesn't exist — a hand tremor, a desk that transmits footstep vibration into the chassis, or a finger that never fully leaves a key all produce a real, measurable change in the reading. Set the reset delta wide and that noise gets absorbed as ordinary travel; set it toward the tenth-of-a-millimetre end Wooting advertises, and the firmware is watching for a signal barely larger than the noise floor it's swimming in. A single physical tap can read as a press followed almost immediately by a release and a re-press — not because the switch bounced, the way an aging contact-closure switch might, but because the firmware was configured to treat a motion that small as meaningful in the first place.

The standard mitigation isn't a smarter algorithm; it's asymmetric configuration. Wooting's own setup guidance recommends per-key settings specifically so a board can run aggressive, shallow rapid trigger on the keys that need instant re-press — a WASD cluster in a competitive shooter — while leaving keys a resting hand actually touches on a wider, less sensitive setting or a fixed actuation point entirely. The guide names L-Ctrl directly as a candidate for a heavier setting, precisely because it's a key players rest a finger on and don't want firing from incidental pressure. The tradeoff is structural, not a bug waiting on a patch: the same sensitivity that buys the latency advantage is the sensitivity that buys the noise exposure, and firmware can only move that dial per key — it can't eliminate the dial.

What this looks like running on shipped hardware

The Gateron Magnetic Jade is a useful concrete case, because its own spec sheet is the analog curve this whole loop consumes: a magnetic flux that climbs from roughly 120Gs at rest to roughly 800Gs at bottom-out across 3.5mm of travel, covered in more depth in the Jade's own deep dive. Nothing about that curve is rapid-trigger-specific — it's just what a Hall-effect linear's sensor reports on every poll, and it's the identical signal a board reads whether rapid trigger is enabled or not. The Wooting 60HE is the board on the other end of that signal: the reference implementation for exposing per-key adjustable rapid trigger over exactly that kind of curve, with the peak-tracking, reset-delta loop described above running per key, per poll, entirely in firmware. Drop a Jade into a 60HE and the same loop runs against a new curve without any firmware change at all — which is about as clean a demonstration as exists that rapid trigger was never a property of the switch to begin with.

What to watch

The more obvious next lever is sensor precision rather than firmware cleverness. A cleaner reading at the same physical distance shrinks the noise floor the loop is fighting without touching the reset delta at all — the argument for tunneling-magnetoresistance sensing over standard Hall-effect that the rapid-trigger plateau piece already flagged as a live axis of competition rather than a settled one. The other lever is exactly the per-key asymmetry Wooting's own guidance already recommends becoming a shipped default rather than an advanced setting a user has to discover: separate downstroke and upstroke sensitivity per key, tuned automatically instead of hand-configured one slider at a time. Until one of those lands broadly, the honest state of the feature is what this piece has described — a firmware loop doing real, useful work, at a cost it can't fully hide, running on hardware that was never the part actually deciding when a key was pressed.