Emulator Issues #12152
[Android] Axis inputs erroneously accept button inputs with the same ID number
Game ID? (right click the game in the game list, Properties, Info tab)
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
What's the problem? Describe what went wrong.
Axis input mappings will accept buttons with same id number as the axis in question. This issue can be difficult to notice in many scenarios, as most gamepad buttons have keyevent IDs in the 96-110 range, while most axis ids are in the range of 0-20. But this issue can become an issue due to the value zero. Specifically, Axis 0 is the X-Axis a commonly used axis on the Left thumstick, while Button Keyevent ID 0 is UNKNOWN, the keyevent that is assigned to all buttons that don't have a mapping in Android's keylayout database. As a result of UNKNOWN essentially being a "null" or "error" button, most applications are coded to explicitly ignore it. Dolphin seems to be unique in not only accepting input from button 0 (UNKNOWN), but also letting the button act as input for Axis 0 (X-Axis). As a result, controllers that have unrecognized buttons will cause Control Stick Right to be triggered when pressed. My recommendation is to add code to ignore all inputs of button 0 and/or add code to ensure that button inputs cannot trigger an axis and vice-versa.
What steps will reproduce the problem?
- Press a button that sends a button ID 0 (UNKNOWN) event
- Axis 0 will triggered as if has a 100% state.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes - 5.0-12115
Is the issue present in the latest stable version?
Yes - 5.0-11991
If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)
[First broken version number here (if applicable)]
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]
What are your PC specifications? (CPU, GPU, Operating System, more)
Qualcomm Snapdragon 845
Qualcomm Adreno 630
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
I can create an Android keylayout file to remap a controller to have a 0 key, if needed for replication/testing purposes.
#3 Updated by Frogperson 4 months ago
I've been having an issue with my Google Stadia controller where pressing either L or R triggers will also send a full right signal from the main control stick, making games such as Mario Sunshine (which rely heavily on the trigger buttons) basically unplayable.
After testing on multiple gamepad tester apps, I've come to the same conclusion as MehStrongBadMeh. The Stadia controller sends Axis 16 and 17 signals for L and R triggers respectively, but each also sends an "UNKNOWN" button press with key code 0. This is being read by Dolphin as a full "1" value on Axis 0, and thus sends Mario racing off to the side whenever I press a trigger.
Hopefully this issue can be fixed soon, because while the Google Stadia service is pretty much useless to me, the controller is actually pretty nice and works very well on my phone, especially when paired with the Claw mount. I would love to be able to use it on Dolphin.
#4 Updated by Frogperson 4 months ago
Decided to dig into the code a bit to see if I could fix this, and ended up finding a working solution (at least for my Stadia controller)
In EmulationActivity, I simply added
// Don't send unknown keycode.
if (event.getKeyCode() == KeyEvent.KEYCODE_UNKNOWN)
to the ACTION_DOWN switch case inside the dispatchKeyEvent() method. This simply stops the unknown keycode from ever being sent to the game, thus preventing the issue from ever happening. I believe this should be safe since gamepads shouldn't be using key code 0 for any actual buttons anyway.