I found some more details on it, I have not verified any of it but they seam reasonable legit.
Can someone test what 2 and 3 do for you ?
So this would be the suggested setting: in_mouse -1
1) Raw mouse input has no negative acceleration which is present in standard windows mouse input (in_mouse -1) due to low resolution, high mouse speed or high DPI of the mouse.
2) Raw mouse input has no positive acceleration in comparison to standart windows input because there is no pointer ballistics applied to it. This means that there is no CPL mouse fix needed to be applied if you use this type of input.
3) Raw mouse input uses unbuffered, immediate mouse data. This means that in comparison to DirectInput it has less input lag.
https://www.excessiveplus.net/forums/thread/in-mouse-1-3-problem More useful infos about the other modes:
This is what John Carmack said regarding the in_mouse values he implemented in Quake 3.
Quote:
in_mouse 1: Mouse control with standard win-32 cursor calls, just like Quake 2.
in_mouse 2: Mouse control using DirectInput to sample the mouse relative counters each frame. This behaves like winquake with -dinput. There isn't a lot of difference between this and 1, but you get a little more precision, and you never run into window clamping issues. If at some point in the future microsoft changes the implementation of DirectInput so that it processes all pending mouse events exactly when the getState call happens, this will be the ideal input mode.
in_mouse 3: Processes DirectInput mouse movement events, and filters the amount of movement over the next 25 milliseconds. This effectively adds about 12 ms of latency to the mouse control, but the movement is smooth and consistant at any variable frame rate. This will be the default for Quake 3, but some people may want the 12ms faster (but rougher) response time of mode 2.
It takes a pretty intense player to even notice the difference in most cases, but if you have a setup that can run a very consistant 30 fps you will probably apreciate the smoothness. At 60 fps, anyone can tell the difference, but rendering speeds will tend to cause a fair amount of jitter at those rates no matter what the mouse is doing.
DirectInput on WindowsNT does not log mouse events as they happen, but seems to just do a poll when called, so they can't be filtered properly.
http://www.esreality.com/?a=post&id=1565939
