Lime-3DS-Emulator
Lime-3DS-Emulator copied to clipboard
ryzendew
8bitdo Pro 2 controller X Y button mapping in Android
Is there an existing issue for this?
- [X] I have searched the existing issues
Affected Build(s)
2116
Description of Issue
Using Lime3DS on Android 14. When mapping controller buttons in the Gamepad settings, buttons X and Y appear as Virtual: Button 67 and Virtual: Button 62 instead of 8BitDo Pro 2: Button 99 & 100, as all other buttons do. This makes the X and Y buttons unusable. They do not work in the game. Note that the controller works fine with all the other emulators.
Expected Behavior
The buttons should map as 8BitDo Pro 2: Button 99 & 100, just like all other buttons.
Reproduction Steps
Map buttons on 8BitDo Pro 2 controller. See that only X and Y show as Virtual buttons.
Log File
System Configuration
Xiaomi 13T running Android 14
I do not have access to this controller and all controllers which I have tested have worked fine, so I can't really debug this
I do not have access to this controller and all controllers which I have tested have worked fine, so I can't really debug this
I have the controller and I can help. I just need guidance. Tell me where to look/how to debug further and I can help you. The X and Y buttons are mapped to buttons 8BitDo Pro 2: Button 99 and 8BitDo Pro 2: Button 100, as seen by Android. I tested in other applications. Maybe they overlap to some values you used internally for the virtual buttons?
I have this controller and can test whether I have the same problem. Maybe this evening.
Which mode are you using?
I have this controller and can test whether I have the same problem. Maybe this evening.
Which mode are you using?
I am connecting to Android in mode D. All other emulators detect those buttons properly (DraStic, PPSSPP etc).
Hi,
I'd like to chime in and say I have the exact same issue with my Odin 2 mini, utilizing Lime3DS build 2116. I cannot map to the "X" button, and instead I get "virtual button 62".
I do not have this issue with any other emulator being utilized.
I just tested 2115, 2116, and the latest dev build with my 8bitdo pro 2 on D mode and was unable to produce this bug. It mapped fine for me. I have asked some acquaintances with odin 2's to try if they have the bug, but for now I'm unfortunately unable to help.
A little research found one other person on reddit who had a similar problem on Citra canary 8 months ago, with a different handheld/controller. I'm thinking this is maybe something unique to your devices or some sort of bug in the android data. My not-very-helpful suggestion, if you haven't done it, would be to close the app completely, wipe the cache and data from the android app menu (this will lose some settings like your touch overlay, but will not delete your lime3ds folder, so your saves and some settings should be safe), and try setting it up again.
Adding that I tried using my own xbox one controller via bluetooth on my Odin 2, and the same issue persists. Perhaps this issue seems to be associated to "xbox" styled controllers? My Odin 2's own controller is reported as an Xbox controller, as an FYI.
I think I figured it out; it seems as though Lime3DS is registering the physical press down and the subsequent release of a button as 2 different inputs. When mapping it to the "X" button. I managed to properly register my physical Y button to the "X" button mapping on my Odin by pressing both the Y button and the option on the screen to map, then the button registered properly immediately as the button was released.
Strange issue, as it doesn't appear to happen when attempting to map any other button.
I just tested 2115, 2116, and the latest dev build with my 8bitdo pro 2 on D mode and was unable to produce this bug. It mapped fine for me. I have asked some acquaintances with odin 2's to try if they have the bug, but for now I'm unfortunately unable to help.
What OS are you on? What version of Android and what "skin" (OneUI, MIUI etc)
I think I figured it out; it seems as though Lime3DS is registering the physical press down and the subsequent release of a button as 2 different inputs. When mapping it to the "X" button. I managed to properly register my physical Y button to the "X" button mapping on my Odin by pressing both the Y button and the option on the screen to map, then the button registered properly immediately as the button was released.
Strange issue, as it doesn't appear to happen when attempting to map any other button.
Ha! Interesting find! It works for me. So, if I press the screen to map the X/Y button and in the same time the physical button on the gamepad it maps correctly to the 99&100 buttons. I wonder why only X and Y trigger this behaviour and not all others? Also, why only in Citra/Lime3DS and not in any single other program....
Now that you describe it that way I realize I had a similar problem with my gamesir g8 Galileo one of the times I mapped it. I will see if I can reproduce later and maybe dig into the code. It may be a while though I have a busy week ahead.
I just tried, its not reproducing. I am getting a different annoying bug that I'll make a separate issue for that might be related somehow. My instinct is that maybe this has something to do with the code that lets you navigate the menu with the controller...
I just tried, its not reproducing. I am getting a different annoying bug that I'll make a separate issue for that might be related somehow. My instinct is that maybe this has something to do with the code that lets you navigate the menu with the controller...
I can confirm that pressing Y or A, both select the current menu options in any Lime3DS settins menu page (and overall in Android as it seems), and pressing B goes back. So it might interfere with the menu naviagtion. But pressing X does nothing. So I can't understand why it reproduces with X and not with A, which has the same function as Y apparently.
I just tested 2115, 2116, and the latest dev build with my 8bitdo pro 2 on D mode and was unable to produce this bug. It mapped fine for me. I have asked some acquaintances with odin 2's to try if they have the bug, but for now I'm unfortunately unable to help.
What OS are you on? What version of Android and what "skin" (OneUI, MIUI etc)
Hi, I'm on android 13 with no skin. It comes barebones on the Odin 2 mini.
I'm having similar issues using the BSP-D8 controller on Android 14. I've tried connecting in different modes (X Input, Android, Switch), either the X or Y button is mapped to a virtual button or doesn't detect the button at all.
I'm having similar issues using the BSP-D8 controller on Android 14. I've tried connecting in different modes (X Input, Android, Switch), either the X or Y button is mapped to a virtual button or doesn't detect the button at all.
Can you confirm that you can actually map the buttons with the workaround described a few posts above, all works fine?
So, if I press the screen to map the X/Y button and in the same time the physical button on the gamepad it maps correctly to the 99&100 buttons.
This issue has been marked as stale. If there is no activity within the next 10 days, this issue will be closed.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Seems to not be an issue for me anymore in Azahar 2120.2, tested on Android 15 (HyperOS 2.0.3.0). Button mapping is correct without any workaround.
I'm still experiencing this issue on Azahar 2120.2 with my GameSir X2s Type-C controller. Holding down the Y button before tapping on the option to bind it in Azahar, then releasing it when the prompt appears does seem to work around the issue.
I'm still experiencing this issue on Azahar 2120.2 with my GameSir X2s Type-C controller. Holding down the Y button before tapping on the option to bind it in Azahar, then releasing it when the prompt appears does seem to work around the issue.
Can you also share your OS information?
Can you also share your OS information?
I'm using a Google Pixel Fold running Android 15 (BP1A.250405.007.B1, Apr 2025). Also, originally I was using a fork of Azahar based off of 2120.2, but I can now confirm this also occurs with upstream Azahar 2120.3.