By England injx - Reply to #36
If you have a high polling rate, there are multiple samples per game frame. No samples are ever dropped or ignored - doing so would lower your effective sensitivity which would be extremely noticeable.

The details of what happens depends on which input method you are using, but they all qualitatively do the same thing. The multiple samples of mouse movement are added together to produce one 'big' sample, which gives you the mouse input for the current frame. This single movement is then scaled and filtered using the usual cvars to update the state of the game.

Now, as you have found, the m_filter cvar was originally added to solve the win95 problems of 40Hz polling. The filter takes the input for the current frame and averages it with the input from the last frame - there is no explicit delay or 'waiting' as you put it, however there is some implicit delay-esq effect due to the filter. As the quote explains, the filter is based on game frames (it has to be as it doesnt know about samples, it only has one input for each frame as explained above), and so the effective strength of the filter depends on the framerate - at 125fps, averaging two frames of input is hardly noticeable (8ms of input is small), but if you have 10fps the same operation involves a large amount of input (100ms from each frame).

This is the reason for extending m_filter from just two frames up to multiple frames, so it can be more useful at a high framerate to those that like the effect.

The modern reason for using m_filter is nothing to do with its original purpose - no one has a polling rate lower than their framerate. There is no problem with samples or lost input. It is just a smoothing effect that some players may like in small doses. Although you are correct about 125Hz giving you 1 or 2 samples per frame with an unstable framerate, which m_filter can help to smooth out. But a higher polling rate is a better solution.