ValveSoftware / ValveSoftware/Proton

Proton 5.0-5 High Polling Rate Fix = non sequitur, please report 1000 Hz mice bugs

Open
#3,700 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
32.8k
Forks
1.6k
PR merge metrics
PR metrics pending

Description

The change mentioned as the fix to regression for high polling rate I can only guess fixed somethings but made some things irreparably worse https://github.com/ValveSoftware/Proton/wiki/Changelog#50-3 I'm surprised only I'm reporting on it. If anyone notices similar issues using a 1000 Hz pro-gamer mouse polling rate please give a response here.

I play a game using OpenGL code that is outfitted with mouse input: DirectInput API, Win32 (with cursor ballistics), and Win32 (Raw Input excludes all Window Cursor accels).

Standard practice is to use the Win32(Raw) to negate all accels or simply use the Win32 input assuming accel should also be off. DirectInput works noticeably fine too.

On 125 Hz mouse things seem normal as on 4.11 branch (I've tested using a Microsoft Wheel Mouse). The moment you use 1000 Hz pro-gamer mouse you get treated to something awful. Maybe its the mesa version 20.0 but I doubt it because the 4.11 branch works fine.

1000 Hz a negative acceleration is deeply ingrained in my game. Accel is off on the OS-level. Raw input should negate any accel coming from the Wine environment. No... the slower I move my mouse hand the more accurate the sensitivity is to how it should be but if I move my hand very fast my distance traveled is 1/3rd as much.

In addition: the overall sensitivity in the game is now 1.80-1.84 times slower. This game uses same sensitivity as many other games (similar formula for 360 degrees) and it's clear what the original speed should be.

I'm not too optimistic if this will be fixed. I'm using 4.11 branch for now and praying it doesn't get messed up either. It's really not a surprise for me because historically even when Loki games was porting Linux titles over, many had some kind of acceleration glitches for 4-5 years before a fix was done. I don't understand why no one else is seeing this. My Logitech mouse is quite popular. Many people using Mesa 20.0, and OpenGL many games running on.

I'm hoping more people can chime in and give a penny.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the report with Proton 5.0-5 using a 1000 Hz mouse, comparing the OpenGL game's DirectInput, Win32, and Win32 Raw Input paths against a 125 Hz mouse and the 4.11 branch. Done means fast mouse movement no longer produces negative acceleration and the game's overall sensitivity matches the expected value.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.