In this update two changes were made to the mouse input code. These two new features are independent - one can be used without the using the other. Since input scaling is very important to players, I wanted to include some sort of documentation which will help you to take advantage of the new features.
1) New Accel Options
For many years Quake engines have had a mouse acceleration option (cl_mouseAccel) on top of the usual base sensitivity setting. Although this defaults to zero (off), many players like to use it - the idea being that one can have both a low base sensitivity for accurate tracking while still being able to do a quick 180 degrees or a rocket jump comfortably.
During Quake Live's closed beta period, a new form of mouse accel was added: the idea was to give players more options to configure the accel curve. Unfortunately this new accel wasn't compatible with the existing accel, so it was added as a separate style ("style 1"). After its addition, it became clear that the style 1 accel suffered from certain undesirable mathematical properties - framerate dependence being one example. These are issues that the trusty style 0 accel didn't have.
In this update, style 1 accel has been removed, and the extra mouse accel features (an offset and a configurable power) have been added in a way which extends the traditional style 0 accel without breaking any of the important mathematical constraints. This means that you can now configure your accel with the following options
cl_mouseAccel - the usual amount/strength of acceleration (default: 0)
cl_mouseAccelPower - the power of the accelerating term (default: 2)
cl_mouseAccelOffset - the mouse speed at which acceleration begins to apply, below this speed the sensitivity is constant (default: 0)
cl_mouseSensCap - an upper limit on the sensitivity, the sensitivity will not be accelerated beyond this value (default: 0 [off])
The default settings for power=2 and offset=0 give you the traditional acceleration previously known as style 0.
When configuring mouse sensitivity and acceleration, the physical meaning of the values you enter depends on factors outside of the game itself, namely the mouse's CPI (counters per inch, also referred to as DPI by most hardware manufacturers) and anything which manipulates the mouse input before it gets to the game (e.g. a driver-level sensitivity setting). A result of this is that one player cannot directly compare his in-game settings with another player - the external factors must also be taken into account for such a comparison to be meaningful. Changing from one mouse to another can also be a pain. In the past, players would perform a physical measurement with a ruler, or use a calculation to determine values which are meaningful (e.g. sensitivity in terms of cm/360). Although this procedure isn't too bad when talking about the base sensitivity, for more complex settings like acceleration, things can get rather messy.
In this update, a new cvar has been added (m_cpi) to solve this problem. By setting m_cpi to the effective CPI of your mouse, the input code can perform scaling in meaningful `natural' units (cm, degrees, seconds), rather than the arbitrary hardware-dependent units of `counts'. The default value is 0, which turns off the feature.
If two players are both using their correct values of m_cpi, they can compare their mouse settings directly from the cvars - this applies to both the base sensitivity and ALL acceleration cvars. For example, the sensitivity will be in units of degrees per cm, and cl_mouseAccelOffset will be a mouse speed in cm/s. This also means that if you are using m_cpi and you change to another mouse, m_cpi is the *only* cvar you have to change.
In order to set m_cpi correctly, it should take into account any driver-level sensitivity setting. For example, you have a 1000cpi mouse with a driver setting of x0.6 - you would set m_cpi to 600, not 1000. I refer to this as the `effective CPI'. If you do not have any driver settings, then just set m_cpi to the cpi of your mouse. Note that the value quoted in your mouse's documentation may differ very slightly in practice depending on the mouse surface, additional mouse feet, etc.
This feature is designed to be used with m_yaw at its default value of 0.022 (using another value will still function, but will no longer benefit from using the natural scale). You can still use m_pitch to provide your vertical axis with a different scale factor.
Old to New Conversion
In order to convert your existing sens and accel settings to the new scheme with m_cpi, there are some existing calculators out there that will do the conversion. If you want to do this manually, you can use the following formula for conversion from old to new.
new_sens = old_sens * (old_yaw * m_cpi / 2.54)
new_sensCap = old_sensCap * (old_yaw * m_cpi / 2.54)
new_accel = old_accel * ( old_yaw * (m_cpi/2.54)^2 ) / 1000
new_pitch = old_pitch * (0.022 / old_yaw)
new_yaw = 0.022
This assumes the old settings are style 0 (power=2 and offset=0).