Controller 'joystick mouse' assignment has massive cursor drift.

[clownfish]

I've successfully created a controller profile that works with the Wiimote's gyro sensors for mouse-like aiming. Unfortunately, the way that the Steam handles joysticks makes the experience less than perfect.

While the Wiimote's Gyro data is not currently supported by the Steam Input API ( I use Moltengamepad to translate), I've detected a problem with how joystick filtering works which might affect other controllers.

Basically, I get the Wiimote's gyros to work by assigning them to a virtual controller's joystick, which is then mapped to a 'joystick mouse' inside Steam. If I disable the deadzone for the joystick, the result is a very responsive gyro-mouse. however, there is significant drift which renders it unusable. This drift is the main issue which shouldn't be there.

At first I thought this drift was the result that happens when you translate gyro data through so many steps, but another program shows that this isn't the case.

If I use the program called AntiMicroX to map the virtual joystick to mouse movements, the result is a very smooth, responsive 'joystick mouse' that has no drift. The result is very similar assigning the Wiimote's gyro axes directly to relative mouse movements.

Also, when testing with a Steam Controller, I also noticed that 'joystick mouse' didn't quite behave like I expect.

[austinp_valve]

You can tweak the deadzone settings for the joystick->mouse mode in the configuration for the game or universally under settings->controller->calibration & advanced settings.

[clownfish]

I need to remove or at least reduce the deadzone substantially because it makes precise/accurate mouse movements rigid and impossible to do.

The problem is that the Steam Input API seems to be injecting a constant downward movement that isn't caused by the 'joystick'. I come to this conclusion because other applications that create a 'joystick mouse' do not exhibit this drift, even when the deadzone for the joystick is removed/reduced to near zero.

In the settings for calibration that you mention, you cannot lower the deadzone below 2000 points. In order to completely remove the deadzone, one must go into a controller profile, disable deadzone and then also enable the anti-deadzone option. However, when enabling this option, it instantly causes a constant downward drift.

I have a feeling that this anti-deadzone, coupled with the artificially imposed deadzone minimum of 2000 points might be the problem. Is there a way that I can force Steam to remove the artificially imposed minimum deadzone in the calibration settings without using the anti-deadzone option? If I can do so, it might end up revealing that the anti-deadzone option is injecting foreign joystick movement.

[austinp_valve]

Did you turn on "anti-deadzone"? That would always put a bit of output on a direction and could possibly cause what you're describing.

2k units is really small - smaller than you'd ever want to apply on a real HW device. The recommendation from Microsoft for games to use for Xbox controllers is ~8k units (https://learn.microsoft.com/en-us/windows/win32/xinput/getting-started-with-xinput#dead-zone). When passing joystick to the game you can disable the deadzone, but if you disable deadzoning entirely on joystick->mouse on a joystick you will have constant mouse movement.

[clownfish]

Yeah, I've tried all options. Enabling anti-deadzone was suggested as a way to disable the 2k deadzone limit, which exists despite selecting the 'disable deadzone' option. However, the drift isn't from the Wiimote. I've tested with multiple programs across Linux and Windows and drift isn't much of a problem. It occasionally happens, but the drift direction isn't predictable or common, and recalibration easily removes it. In Steam, the drift is a constant downward direction even when the Wiimote gyros are calibrated.

I understand that physical joysticks don't need to be below a 2k deadzone, but I'm describing a situation that uses a virtual joystick mapped from gyroscopic data. The 2k deadzone limit does have a noticeable effect. The difference is being able to aim at a targets within ~5 pixels of each other (with no deadzone), to not being able to aim at anything less than ~20 pixels away (i.e. movement 'jumps').

Regardless if one 'needs' a deadzone, removing it (if that's what the anti-deadzone actually does) is injecting foreign movement that shouldn't be there. The source of this movement, I believe, is a bug.