I am using RAW input. All is working correctly, if I disable mouse acceleration. But that is not really a user-friendly solution. How can I use raw input with mouse acceleration? I mean, how to multilply retrieved values to get the same effect as windows primary do?

Second approach would be to disable acceleration only for my application. I kind of already tried that, but I dont like this solution. When app crash, default values are not set back and acceleration stays turned off.

It's not clear what you're asking. Do you mean that you want to implement Windows' mouse acceleration formula on top of raw input (WM_INPUT)?

Or that your raw input is affected by Windows' acceleration setting and you want to turn it off? - this shouldn't be the case in my experience. Raw input is raw. It shouldn't be affected by the Windows setting.

The first one.. my RAW input is not affected by accelartion and I want to affect it. I have app, that combine GUI and OpenGL window. Turn off acceleration for my app is not a solution, since I want to leave it for GUI elements. I can check if mouse is in GL area or not, but that is my last solution. I would rather implement Window´s accelration on top of WM_INPUT by myself.

The best way to do that is to just use the standard WM_MOUSE* messages when your GUI is active.

How would turning off acceleration help you implement your own acceleration? That makes no sense.

You can find the formula Windows uses for it's acceleration all over the internet. I found this: http://donewmouseaccel.blogspot.ro/2009/06/out-of-sync-and-upside-down-windows.html

The best way to do that is to just use the standard WM_MOUSE* messages when your GUI is active.

Not correct. Read the original documentation.

I read that once, but it doesn't say much about mixing the regular mouse input with raw input? In fact, I think it says you can still use the legacy mouse messages along WM_INPUT - you can tell raw input to allow legacy messages during device registration.

And I don't think that the Windows acceleration makes sense for anything other than just the UI elements, since (according to the article I linked to), the acceleration is relative to the screen resolution and DPI setting in Windows (not even the physical DPI), not the physical resolution of the mouse. I don't know why anyone would want to emulate this type of acceleration.

I read that once, but it doesn't say much about mixing the regular mouse input with raw input? In fact, I think it says you can still use the legacy mouse messages along WM_INPUT - you can tell raw input to allow legacy messages during device registration.

No there's no such thing in the documentation.

For event based applications the WM_MOUSE_MOVE is enough. For simulations running at run-time they don't if you want high DPI input.

Also, if you're using mouse raw inputs it is considerable to use keyboard ones as well.

I think you have something confused. If you're trying to drive a cursor in your game for GUI interaction, you want to use WM_MOUSE* messages and let windows draw the cursor, because then your user gets the expected mouse ballistics. Windows mouse messages come in fast enough for any game that is going to be using a cursor for interaction.

Now if you're doing a FPS with a hidden mouse where the mouse controls where you look, THEN you use Raw Input because all the ballistics are removed.

Using both in tandem with eachother, switching based on what kind of mouse input you want, is perfectly acceptable and not even that hard to do.

Heck, I do the same think for the keyboard. Much easier and cleaner to let WM_CHAR handle text input when a text box has focus and then switch to raw input for actual game controls.

TLDR: There's no reason to only use Raw Input and then re-write all of the Windows code to do proper mouse cursors and text input when you can just ask Windows to do it for you.

Ok.. thanks to all. I have done the combination of WM_INPUIT and WM_MOUSE* and its now OK.