[Linux] Sensitivity Issue

[shoober420]

I know there have been a lot of issues opened about sensitivity problems, but this is quite different. In Goldsrc games, it seems that my sensitivity is off my 2 inches. I use an Intellimouse 3.0 which has 400DPI. I play with "3.5" sensitivity and no accelleration, so I should do a full 360 at 29.6cm (11.6in). Instead, it takes me 34.6cm (13.6in) to do a full 360 in game. It seems that the sensitivity is off by exactly ".5". I have to add an additional ".5" to my sensitivity to actually do a 360 at 29.6cm (11.6in). I have tried disabling raw input, but its still is the same. I also added -mousethread to the launch options and that didn't fix it either. The only way to fix it is by adding ".5" to my sensitivity. So using a sensitivity of "4" is the only solution. I can't say if this occured before the updates because I never tested it like this. I have done this exact test in Source games (CSGO with raw input enabled) and Quake 2 (R1Q2 with raw input enabled), and I do a 360 at 29.6cm (11.6in) with "3.5" sensitivity like I should. It only seems to be a problem with Goldsrc games.

[dtugend]

Not sure if this helps you, but maybe you didn't take the values of m_yaw and m_pitch into account:

Assuming that the code actually matches what Half-Life 1 and Counter-Strike 1.6 do, one can see form input32w.cpp#L411 and input32w.cpp#L544, that assuming you have m_rawinput 1 and m_customaccell 0 the pitch and yaw are calculated as follows:

delta_yaw_degrees = mouse_delta_x * sensitivity * m_yaw delta_pitch_degrees = mouse_delta_y * sensitivity * m_pitch

(The resulting total pitch is limited to max values afterwards, as you can see in the code linked above.)

Edit: Btw.: mouse_delta_x and mouse_delta_y are what it gets from SDL_GetRelativeMouseState.

Meaning on Windows systems those are (accumulated) from WM_INPUT messages

[dtugend]

Example for a 360 degree turn: m_rawinput = 1 m_customaccell = 0 sensitivty 3.5 m_yaw = 0.022 delta_yaw_degrees = 360

mouse_delta_x = delta_yaw_degrees / (sensitivity * m_yaw) = 4675

4675 dots / 400 dpi = 11.7 inch

Okay, now I can see where you got the values from. Meaning my post above won't help you, I guess. Now the question is, why it doesn't do what we expect it to do?

Does it matter if you move the mouse slower? Do you have m_rawinput 1?

[dtugend]

I have a Logitech RX 250, which is advertised as 1000 dpi, so I'd have to move 4,7 inch according to this formulae, but when I move slowly I have to move about 8.3 inch (which roughly equals 500 - 600 dpi).

Please repeat this test: Set your mouse cursor to the right edge of your desktop. The move it slowly to the left edge of the desktop. Then calculate dpi = desktop_width / inch mouse moved. For me it is 1024 dots / 1.97 inch = 520 dpi.

Meaning for me The movement in Counter-Strike matches the movement of the mouse on the desktop.

I am on Windows XP and don't have special mouse drivers installed. In case you have special mouse drivers installed, please check that the mousedriver doesn't force different settings for Half-Life games (hl.exe), I have a different mouse and it has different profiles for different games in the driver, maybe that's where your problem is coming from.

[shoober420]

Not sure if this helps you, but maybe you didn't take the values of m_yaw and m_pitch into account:

Yaw and pitch are at default in all the games I tested. This is not the problem.

4675 dots / 400 dpi = 11.7 inch

Its technically "11.688311688311689 inches", I just didn't feel like typing it all out, so I shortened it to "11.6".

Okay, now I can see where you got the values from.

Use this site, its a lot easier.

http://www.funender.com/quake/mouse/index.html

but when I move slowly I have to move about 8.3 inch

Sounds like you have windows accelleration enabled. Make sure "Enhance pointer precision" is unchecked under your mouse settings. If it is, you need to get the "Cheese mouse fix" or the "Mark C mouse fix". I use the Mark C mouse fix. Since you're on XP, you should get the "Cheese mouse fix". This mouse fix makes it so my mouse moves the same distance, no matter how fast or slow I'm moving my mouse. It won't go slower if I move my mouse slower.

I have a different mouse and it has different profiles for different games in the driver, maybe that's where your problem is coming from.

I don't use any driver for my mouse, and I don't use the intellipoint software. This can't be the reason.

This is a problem with Goldsrc games only. My mouse sensitivity is how it should be in all other games. I do use m_rawinput 1 and have m_customaccel set to "0". I'm pretty sure this is problem started after the updates. This might be why everyone is saying the sensitivity is different.

[dtugend]

Using a debugger I have verified / tested that the processing inside the client.dll / input32w.cpp happens correctly, setting the value of mouse_delta_x to 2338 correctly gives an 180 degree turn.

Also SDL2.dll* seems to correctly pick up the deltas from the WM_INPUT messages. So the question is, why the WM_INPUT messages are seeming not be what we expect them to be?

• I am using a custom build version of SDL2.dll, however the WM_INPUT stuff should match the stuff in the .dll that Valve uses.

[dtugend]

@shoober420 can you please repeat the test on the desktop, that I suggested above, so we can see if the desktop mouse movement is correct or if it matches what it does in Counter-Strike for you?

[dtugend]

@shoober420 I have hacked together a WM_INPUT mouse move test program using this example on CodeProject.com:

WM_INPUT_MouseTest.zip (19.1 KiB)

If you are afraid of the binary, I included the Microsoft Visual C# 2010 Express (you can obtain it for free from microsoft.com) source code.

This way you can test whether it's a problem with the raw input data it gets or not.

Edit: The program needs .NET Framework 4.0 Client profile or newer

[shoober420]

I'm sorry, but I don't have .NET 4.0 installed. I have tested CS1.6 with m_rawinput 0 and m_rawinput 1, and the sensitivity problem remains. I also don't completely understand the test with the desktop that you want me to do. Could you explain it to me?

[dtugend]

Would be cool if you could install .NET 4.0 and test it, the Client profile loads about 41 MiB from the internet, there is the web installer and the standalone installer. I can understand though, if you can't for some reason. Btw Windows 8 has .NET 4.5 which is backwards compatible to 4.0, but I assume you are on Vista or Windows 7 or s.th.. If it helps I can also try to compile it for an older .NET framework, which would require me to know your Windows version and thus knowing if and if yes which framework you might have installed. I'd prefer 4.0 or newer though, since otherwise I might need to rewrite code or even end up it being impossible / very hard.

Please repeat this test: Set your mouse cursor to the right edge of your desktop. Then move it slowly to the left edge of the desktop. Then calculate dpi = desktop_width / inch mouse moved. For me it is 1024 dots / 1.97 inch = 520 dpi.

By that I want to calculate the desktop DPI of your mouse, however that will only make sense with a mousefix and pointer acceleration off and the mouse speed slider on the default 6 of 11 position. The idea is to move the mouse a known distance on the desktop, I suggested above moving it from the right of your desktop to the left of your desktop. You can then measure the distance you moved your mouse on the mousepad. You can then calculate your mouse DPI for the desktop by dividing the desktop_width by the distance in inch that you had to move the mouse (the result will be very rough though).

Would be better if you could use the testprogram though, since that one reads the so called "raw data" (at least Microsoft advertises it to be raw), like SDL2.dll should, so we could see if the problem is already in Windows / with the mouse or if the problem is elsewhere (since like said I used a custom built SDL2.dll and not the original one shipped alongside with hl.exe, so I could do some debugging easier).

[shoober420]

None of that is necessary since I know it only happens in Goldsrc games. My mouse can only do 400DPI, so no matter what, my mouse and desktop DPI will be 400DPI. I use the MarkC mousefix, windows acceleration disabled, and a 6/11 windows sensitivity. This has nothing to do with raw input, since I get the same results if I disable raw input in Goldsrc games.

[dtugend]

So you are basically claiming that Goldsrc games are not using rawinput despite m_rawinput 1.

If that is true, then the mouse should be slower / faster when you change the windows sensitivity (use the extreme values). (For me windows sensitivity has no effect with m_rawinput 1, it works the same as the mouse test program says.)

Furthermore I assume (hope) you have m_filter 0.

[shoober420]

So you are basically claiming that Goldsrc games are not using rawinput despite m_rawinput 1.

I never said this. I'm saying that the sensitivity is wrong whether or not raw input is enabled or disabled. Its about ".5" off of what it should be (when using m_rawinput "1"). Instead of using my sensitivity of "3.5" (like I do in CSGO with raw input enabled, which gives me 29.6cm/360), I have to use a sensitivity of "4" in Goldsrc games to achieve this. If I use "3.5" in Goldsrc games, whether or not raw input is enabled or disabled, my sensitivity is 34.6cm/360. I of course have my m_filter set to "0".

UPDATE: I have just discovered something even worse. When you disable raw input, the sensitivity is lowered even more. I went into game and set m_rawinput to "0", and I set my sensitivity to "3.5". It took a whopping 15.6in to do a full 360. There is definitely something wrong with the sensitivity in Goldsrc games.

[dtugend]

Can you please test, if the turning in-game with the mouse is slower / faster when you change the windows sensitivity (use the extreme values)? If GoldSrc is working somewhat correctly there should be a change with m_rawinput 0, but none for m_rawinput 1 (at least that is what I'd expect).

[shoober420]

This has nothing to do with the problem. Even when using m_rawinput "0", I should do a 360 at 29.6cm. The sensitivity is all screwed up in Goldsrc games.

[dtugend]

I understand that it should do that due to the mousefix etc.. I understand that it does seem to work in Quake 2 and Source engine mods for some reason for you and can't offer an explenation for that. I understand that my questions and requests may seem unrelated and annoying.

The problem is, I can't see anything wrong with rawinput in the code neither in the (stable) official GoldSrc version* (please make sure that your version matches, see bellow) nor in the SDL2.dll that that version uses.

That's why I am asking stupid questions, because I try to find out where the problem starts without debugging your PC.

*] version Protocol version 48 Exe version 1.1.2.7/Stdio (cstrike) Exe build: 13:14:12 Aug 29 2013 (6153)

Please don't forget to post your system info as Valve suggests here it may become helpful for them.

Also it would be interesting to know how you measure the distance in cm that your mouse travelled on the mouse pad, I did it by using a ruler and measuring the actual distance?

[shoober420]

I used a ruler like you. Your questions aren't stupid, its just I don't think raw input is the problem. I verified the game cache of CS1.6 and HL, so I must be using the latest SDL2.DLL. I'm opted in both the HL and CS1.6 beta. Maybe you should load up a Source game and see if your sensitivity is different also. I can almost guarantee it is.

Windows 7 64-bit Radeon 4890 4GBs DDR2 800MHz X-Fi Titanium Intellimouse 3.0

[dtugend]

I'd love to try that / I'd love to help. But I only have Counter-Strike Source and it doesn't run on my laptop (anymore) (cause it requires SSE2, which it doesn't have).

:...(

Fun fact on the CS:S page it says minimum requirements is SSE, but it's actually SSE2.

[shoober420]

Do you own any Quake games? Try it in those.

[dtugend]

1) Turns out the Logitech RX 250 is crap, if I move it fast I get 1000 dpi as I should, if I move it slow I get only 500 dpi. With a Logitech MX518 I get nearly the same dpi (800) whether I move it fast or I move it slowly.

Anyways, with the Logitech MX518 I have to move about 5.8 - 6 inch for a full turn in Counter-Strike 1.6 with m_rawinput 1, nearly independent of the speed I move at (meaning it works the way it should for me).

2) I tried the q2-314-demo-x86.exe (Quake 2 Demo) and it's driving me nuts, there doesn't seem to be a way to enable rawinput in the demo. I am using the CPLmousefix, meaning I should have to move 5.8 inch here too, but I have to move a full 8.27 inch for a 360 degree turn (and yes I have set sensitivity to 3.5).

I cannot explain my findings, but those are the results :-(

I could test Warsow if that helps anything? It has rawinput (m_raw 1, m_filter 0) too.

[dtugend]

Okay, seems to have been a problem with the CPLmousefix, with the Cheesemfix* I get about the same distance in Quake II Demo (sensitivity 3.5) as in Counter-Strike with rawinput (14 - 16 cm for the Logitech MX518 which runs at 800 DPI).

Hm :-(

* I use the Cheese mouse fix 60.reg, because 60 hz is the refreshrate of my Desktop / LCD, I hope I am doing this right.

Edit: In Warsow I get with m_filter 0 and m_raw 1 about the same movement (14 - 16 cm).

[shoober420]

Since you're using Windows XP, and I'm using Windows 7, maybe there lies the problem. I recently played some Quake 1 using the Quakespasm client, and my sensitivity is the same in Quake 1, as it is in Source games and Quake 2. Goldsrc games are the only games that have this problem with sensitivity. When I disable raw input in Goldsrc games, my sensitivity is even slower. This shouldn't happen since I use 6/11 windows sensitivity. I should have the same sensitivity whether or not I have raw input disabled or enabled.

Back when I used Rinput for Goldsrc games, my sensitivity was not effected like this. I have no idea what the update did to the mouse input, but its screwed up really bad. There have been many others who have reported that the sensitivity is way differerent after the update.

[shoober420]

Hey ripieces, I thought of something. Are you enrolled in the CS1.6 BETA? I am, and maybe that has something to do with it. Could you check to see if you are enrolled in the beta also? You have to right click on CS1.6 and go to properties. Then go to the "Beta" tab and choose the "SteamPipe Beta". If you haven't done this already, please enroll in the beta, then see if the results are the same. I'm still experiencing this issue. I installed TFC today (also SteamPipe Beta), and have the same sensitivity issue. I still have to add about .55 to my sensitivity to get the same sensitivity with other games like CS:GO. So for example, I play with 3.6 sensitivity in CS:GO and all other games, so I have to set my sensitivity to 4.15 in Goldsrc games for it to feel like 3.6. I used a ruler and everything, and it needs almost exactly .55 to measure the same distance.

[dtugend]

@shoober420 I signed into the beta (both HL1 and CS 1.6), however I strangely get the same version for the beta and non-beta (despite downloading and updating files by Steam when the BETA subscription is changed): ] version Protocol version 48 Exe version 1.1.2.7/Stdio (cstrike) Exe build: 13:14:12 Aug 29 2013 (6153)

I am not sure if this is a bug, or if they updated the beta branch to match the non-beta branch.

Of course the behaviour of beta and non-beta is thus the same for me, being the way it should be according to your calculations (it's a bit off, but that's within limits).

One thing a noticed: For me it's called "BETA - BETA" and not "SteamPipe Beta". Also when in the beta branch a "[BETA]" is displayed behind CS 1.6 and HL1 for me.

Maybe s.th. is wrong with your installation / maybe it's broken?

I'd recommend that you compare the version output of your game to mine. Also try signing out of the beta and compare your version output and game mouse behaviour then.

I should note, that I did all my tests in windowed mode, not sure if fullscreen would make a difference.

[shoober420]

I have the same version of the game as you. I have recently installed Linux, and this problem still occurs. Its even more drastic. If I use the -mousethread launch option, I have to set my sensitivity around 2 for it to feel like it does in windows with 4 sensitivity. If I remove the -mousethread option, its back to having to set to 4, just to have it feel like it does in all other games that use 3.5.