Option needed to disable OS-level adjustment for mouse acceleration

[NavidZ]

Some games need to disable mouse acceleration to achieve a better gaming experience (1, 2).

I believe this best fits in the pointerlock request api as an option to provide such a capability. Here is the Windows API allowing to disable that.

@smaug---- @EiraGe WDYT?

[EiraGe]

It sounds reasonable to me for letting developers be able to match the physical mouse movement and events movement.
A quick search on the internet I founds it's possible for player to disable mouse acceleration on the OS (except chromeOS crbug.com/589190). Considering gaming user might like to make their own choice on mouse preference, although a bit complicate, I feel adding this is actually less important.

[NavidZ]

Is it normal for the games to have this option within them? Or do people usually go and change the settings in their platform to achieve this?

[EiraGe]

I'm not familiar with gaming area, so I have no idea how people usually do. I think changing the setting in the platform seems very complicate, so it'd be nice to have this.
I'd also like to have more game developers' opinion to know whether this will help or not. (The cros bug has really high number of stars)

[smaug----]

I don't have enough experience on games to say what is preferred here. I would expect people to look at the platform prefs. Perhaps @juj has some feedback to this.

[scheib]

Initial specification discussions did include this topic. The spec FAQ summarizes as in 12.4 https://www.w3.org/TR/pointerlock/#why-bundle In email group discussions it was raised that some games do use raw mouse movement, before OS level adjustments. Those adjustments are tuned to making a relative motion pointer work well. Other uses of mouse movement may not work well with those same curves. E.g. First person viewpoint adjustment. Further, there are also higher resolution updates for precision aiming. The 2011 specification selected a pragmatic choice of shipping something that could be clearly specified and consistently implemented across platforms. It handles the majority of client applications -- there are many web games using pointer lock after OS level adjustments to inputs. See discussions in the proximity to: https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1043.html If there is developer demand, I personally do believe an iteration that provides increased access to raw mouse input would be useful.

…

On Tue, Oct 2, 2018 at 8:20 AM smaug---- ***@***.***> wrote: I don't have enough experience on games to say what is preferred here. I would expect people to look at the platform prefs. Perhaps @juj <https://github.com/juj> has some feedback to this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#36 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXnmxM8OMYPpJp7y7gV3dh1zoM7c3a4ks5ug4QmgaJpZM4Wn7_N> .

[juj]

Games do commonly provide options to users to choose mouse sensitivity, and also sometimes provide options for enabling or disabling mouse acceleration. E.g. Counter-Strike:

MineCraft has only a sensitivity setting:

On Windows based games for example, mouse acceleration control is done by switching between Win32 UI Mouse Events API that provides OS-level accelerated/nonlinear input, and Raw Input API that provides linear unaccelerated mouse movement.

The first API reports movement taking into account user's mouse sensitivity and acceleration settings in Windows Control Panel, whereas the second API provides raw input data directly from the mouse device.

If user has disabled mouse acceleration in their Mouse control panel, then Win32 UI events report unaccelerated content, but it is rare to expect players to go manage mouse acceleration and sensitivity for individual games via control panel, hence games providing custom options.

Whether linear or nonlinear acceleration should be used for first person content or some other types of games is a highly subjective experience. E.g. some Counter-Strike players prefer to have acceleration enabled, others prefer to disable it. But both usages are common.

I would recommend here to provide an option in pointer lock to choose between raw/linear input and desktop/nonlinear input. (Recording both linear/nonlinear input data for one event passed to JS would be technically difficult to implement due to lack of coherency in the received events from the OS)

[binoculars88]

I couldn't explain it better than @juj did above.
As a game developer, I'm definitely rooting for having the option to have as raw mouse input as possible, so we can present our players with options like shown above. Certainly when it comes to releasing for both stand-alone and web, having a consistent mouse movement feel is key for us.

@scheib is there anything in the backlog that would satisfy these desires :) ?

[eliwald]

This API would be immensely useful for us. We need the ability to allow games to switch back and forth between raw (non-accelerated) input and desktop (accelerated) input as necessary, depending on the context of their game. Adding this option to the pointerlock API would unlock this use case! :)

[smaug----]

Based on some feedback, implementing this properly on all the platforms can be tricky. Linux for example has several ways to control acceleration. And I'm not sure even about MacOS.

@EiraGe @NavidZ have you figured out how to implement this everywhere per program (in such way that if a browser crashes, OS still keeps the original behavior)?

[NavidZ]

@whsieh

[scheib]

Work is underway to offer unmodified movement data:

• Specification patch in progress: Add lock options to requestPointerLock #49
• Chromium implementation issue: https://crbug.com/982379 - which is also running an Origin Trial

[binoculars88]

@scheib our users started reporting a bug with pointerlock a few days ago. It seems it started around the 28th of May. Could this be related to the release of Chrome 83? A bit more info on the bug being reported: We have a window saying the pointer isn't locked when that's the case. When users click the window we request a pointerlock again. Never had any issues, but since a couple of days, users complain the window won't go away. We can't consistently reproduce this ourselves, but in the rare case where we see this too, we notice the function gets called but for some reason, the pointer doesn't lock. From that moment on, the Chrome tab seems "broken" and even when refreshing in Incognito, pointerlock will always fail. Only trying it in a new Chrome tab locks the pointer again.

We don't have a lot to go from atm, as we can't reproduce consistently, but I wanted the share this already. The bug is there for sure. We have a very active community, never had bug reports regarding this, but the last days it's one after the other. We haven't made any changes on our side.

We will continue doing tests in the next couple of days. I'll keep you posted if we find something more concrete.

Note: we use requestPointerLock(), not the new requestPointerLock({unadjustedMovement: true})

[scheib]

@binoculars88 It may be related. This forum is for the spec change. Please file a new crbug.com and post a comment on https://crbug.com/982379 indicating that it may be related and we'll take a look. A repro case would help significantly.