Emulator Issues #11741
Switch Pro controller axes are not detected fully in MacOS
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.
Registering inputs for a switch pro controller only accepts inputs from the right analog stick in the vertical direction (Ry) on MacOS
What steps will reproduce the problem?
Connect a switch pro controller to a Mac over bluetooth.
Attempt to set up inputs for the analogue stick axes.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Is the issue present in the latest stable version?
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.)
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
What are your PC specifications? (CPU, GPU, Operating System, more)
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
#3 Updated by RegisterBroken almost 2 years ago
Some additional info: the Switch Pro controllers work on Cuphead, OpenEmu, Controllers and Enjoyable2 (keyboard mapping programs), and some other native macOS games I can't remember (Hollow Knight, I think?). They also work as expected on older versions of Dolphin (as you'd expect).
In my own testing, revision 9793 is indeed the last one that supports them properly.
Looking at the commits that followed, it seems like spycrab's (very much appreciated) changes to the IOKit interface inadvertently broke them. I won't ask to be assigned this issue, because this is my first time looking through Dolphin's code, but I will be looking at the changes made to see if anything stands out.
In the mean time, I really think this ticket's info on Regression, Regression Start and Usability should be updated.
#4 Updated by RegisterBroken almost 2 years ago
In retrospect, I'm not surprised something got missed. The style used is headache-inducing.
Anyway, the default case for unrecognized Axis inputs seems suspect, especially the changes to the related for-loop. I think setting a watchpoint on the
elements argument to
Joystick::AddElements might be insightful, but I don't have enough experience with gdb to try that, and the build scripts use gcc to compile. Are there any debugging tools built into Dolphin itself which may be useful here? There's a call to
NOTICE_LOG here which I think should report something in this case.
#6 Updated by underdisk over 1 year ago
I have no experience with IOKit, so I apologize in case I say something obvious or trivial.
I did tests using my Pro Controller.
First, I wanted to know the element cookies of the sticks' axis
In my case I got those results :
1206 is the last element in the list, and also the only working axis.
I noticed that with the pre-9795 source code, the number of calls to
AddAnalogInputs was 5
I don't know what the 5th one is, but it's close to the 4 obvious axis.
Snippet to the part of the pre-9795 source code I tested:
But on the post-9795 source code, I figured out that the exact same code got called 1135 times. (The Controller is the only device connected to my Mac)
Snippet to the part of the post-9795 source code I tested:
In the current code, the right elements get passed to
AddAnalogInputs but it looks like a lot of other stuff (that also have for usage kHIDUsage_GD_X, kHIDUsage_GD_Y, kHIDUsage_GD_Rx or kHIDUsage_GD_Ry) call the same function
I don't know a lot about IOKit or the reason the code was changed in the first place. But I hope that what I found could help at some point.
#8 Updated by Billiard26 over 1 year ago
I've compared SDLs IOKit handling with our own and there are many things we are not doing that we probably should.
If I remember correctly I talked with a macOS user that had similar controller problems in dolphin while an SDL-using application functioned.
Changes could be made to our IOKit code to more closely match that of SDL, but unfortunately we seem to have zero people who can program, who use macOS, and who have controllers with issues.
We have SDL code in place. I know it functions just fine on Linux. We should probably enable SDL in the macOS build to replace or at least supplement our direct IOKit usage.
#9 Updated by underdisk over 1 year ago
but unfortunately we seem to have zero people who can program, who use macOS, and who have controllers with issues.
I have a Switch Pro Controller (with the issue), macOS, and I'm a C++ dev. I just have 0 experience with low-level macOS stuff (+ it's the first time I take a look at Dolphin's source code)
I can try to take a look at how SDL2 manages IOKit stuff. But I don't guarantee that i'll find something useful.
#11 Updated by underdisk over 1 year ago
I suggest you build dolphin with SDL support.
cmake .. -DENABLE_SDL=1
And see if using SDL solves your problems.
Quite weirdly, the only thing that changes is that the blue light circle and the "first player" indicator on the controller are now glowing (and that's a good thing!). The same problem happens (only right stick's vertical axis working)
But I use my modified source code that might be completely broken by my tests. I'll build the last version and tell you if anything changed.