[Feature request] raw mouse input, no acceleration, with `requestPointerLock({ unadjustedMovement: true })`

[WofWca]

Version of emscripten/emsdk:
3.1.58

This affects shooter games especially. Chromium introduced the unadjustedMovement parameter not so long ago, which makes aiming so so much better, indistinguishable from running a native game.

There is an example of an app, Quake III Arena, that utilizes Emscripten with a hack to get it to use unadjustedMovement:

https://github.com/jdarpinian/ioq3/blob/7801abd5ac510a889087ad62473c54dbe509e106/code/web/index.html#L301-L322

It can be tested here: https://thelongestyard.link/

However, I believe that this should be upstreamed to Emscripten itself. Perhaps with a config option, if needed.

As of 2025-06 it's only supported on Windows and macOS, however, and its support needs to be detected, perhaps with try { await canvas.requestPointerLock({ unadjustedMovement: true }) catch ....
Also note that this parameter is considered experimental.

I wanted to try to make an MR, but I am not sure where exactly this needs to be changed (there is a lot of requestPointerLock references), and how to handle the fact that this option might not be supported.

[sbc100]

If the option is provided but the browser doesn't support it, will it just ignore the extra option or will it fail?

[WofWca]

It will fail, i.e. the promise will reject and I think it will also fire the 'pointerlockchange' event. See how I handle it here:

https://github.com/WofWca/quake3.xdc/blob/be18795b56a0e408514e78201a731f38c1a92bc6/index.html#L398-L419

I believe if the browser did not implement this feature, such as Firefox, it will silently fall back to regular, "adjusted" input, with acceleration and stuff.

[sbc100]

I that case yes, you would need some kind of feature detection.. but it would be tricky since you want to detect the feature without actually requesting the pointer lock.