Without acceleration, a mouse count always moves the pointer the same distance. With it, the distance depends on how fast you were already moving: a slow drag is scaled down and a quick one is scaled up. Both operating systems ship this turned on, and it is the reason two careful measurements of the same mouse disagree.
It is also the reason people conclude their mouse is faulty, their sensor is lying, or their DPI setting never applied. Usually none of those is true. The sensor reported honestly and something between it and the pointer rewrote the number on the way past.
What acceleration actually is
A mouse sensor reports counts — discrete steps of movement, at a rate set by its CPI. Nothing about that changes when you move faster. Move an 800 CPI mouse one inch and it reports 800 counts, whether that inch took a second or a tenth of one.
What changes is what the operating system does with them. Without acceleration the mapping is a constant: every count becomes a fixed number of pixels, so distance in equals distance out. With acceleration the multiplier becomes a function of velocity — the faster the counts arrive, the more pixels each one is worth.
The consequence is the part that matters for measurement: the same physical distance no longer produces the same pointer travel. Two identical drags at different speeds land in different places. Every calculation downstream that assumed a fixed ratio is now working from a number that moved.
Where each system hides it
| System | What it is called | Default |
|---|---|---|
| Windows | Enhance pointer precision | On |
| macOS | No exposed control | On |
| Linux (libinput) | Adaptive acceleration profile | On |
Windows puts a checkbox in Control Panel → Mouse → Pointer Options. Clearing Enhance pointer precision disables the curve. The separate pointer speed slider is not acceleration — it is a flat multiplier, and its sixth notch is the only one that maps counts to pixels one to one. Anything either side of the middle scales your input even with the checkbox cleared.
macOS offers no checkbox at all. It applies a curve to every mouse by default, and switching it off means writing the preference directly:
defaults write -g com.apple.mouse.scaling -1then logging out and back in. The Tracking speed slider in System Settings is a separate control and leaving it alone does not disable anything.
Linux under libinput exposes two profiles. The default is adaptive; setting the flat profile gives a constant multiplier and is the equivalent of clearing the Windows checkbox.
What it does to a DPI reading
Measuring DPI means dragging a known distance and dividing counts by inches. That arithmetic assumes the ratio is fixed. With acceleration on it is not, so the answer depends on how fast your hand happened to move:
| Drag | Reading for an 800 DPI mouse |
|---|---|
| Slow and careful | well under 800 |
| Normal | near 800 |
| Quick flick | well over 800 |
None of those is your mouse’s DPI. A result that lands far from any standard step — 400, 800, 1600, 3200 — is almost always this rather than an unusual sensor setting.
The tell is repeatability. Run the DPI test three times at three deliberately different speeds. With acceleration off, the three readings cluster within a few per cent. With it on, they spread, and they spread in the direction you would predict: slower drags read low, faster ones read high.
What it does to a converted sensitivity
Worse, because the damage is silent. A conversion holds your turn distance constant, and turn distance is only a property of the setup when counts map to degrees at a fixed rate. With acceleration on, a slow turn and a fast turn cover different angles from the same hand movement, so the converted value is correct on paper and wrong in play.
This is the failure people describe as a sensitivity that “feels off” after moving between games. The converter did its arithmetic correctly on the numbers it was given. One of those numbers was a DPI reading taken through an acceleration curve, and every figure derived from it inherits the error.
Raw input is the exception, not the rule
Most competitive games read raw input — they take counts directly from the device and bypass the operating system’s pointer pipeline entirely. That is why acceleration can be on system-wide and a game can still feel consistent, and why the setting is worth finding and enabling wherever it exists.
A browser never does this. Everything a web page receives has already been through the OS curve, which is why any measurement taken in one — including every measurement on this site that involves movement — has to have acceleration switched off at the source. There is no correction that can be applied afterwards, because the curve is not linear and the original counts are gone.
How to tell whether it is on
A two-minute check, with nothing to install:
- Put the pointer against the left edge of the screen.
- Move the mouse right across the mat slowly, in one steady sweep. Note where the pointer stops.
- Return the mouse to its starting position, lifting it clear of the mat.
- Make the same sweep quickly.
With acceleration off, both sweeps land the pointer in the same place, because the same physical distance produced the same travel. With it on, the fast sweep travels noticeably further — often two or three times as far.
The lift in step three matters. Dragging the mouse back along the mat feeds the return journey through the same curve and muddles the comparison.
Turning it off, and what to expect
Expect a week of feeling slower. Acceleration lets a hurried movement cover more ground, and a hand that has learned to rely on that will undershoot for a while once it stops happening.
That adjustment is the point rather than a side effect. A constant mapping is what makes muscle memory transferable: the same movement produces the same result every time, so the distance your hand learns is a distance it keeps. With a velocity-dependent curve, every movement has to be made at the speed it was learned at to land where it landed before.
Set the sensitivity afterwards, not before. Turning the curve off changes the effective speed of every movement you make, so any value tuned with it on is tuned to a mapping that no longer exists.
What it does to click speed
Nothing. Clicking is not motion, and no acceleration curve touches a button event. A click test is the one measurement on this site that does not care — which is worth knowing, because it means a click rate taken on a badly configured machine is still a valid click rate. Movement is the thing the curve distorts, and movement is the thing to switch it off for.