Emulator

The main one is from Dolphin versions 9793 and below although I'm not sure when the support was originally added as it doesn't work in the stable release. It also works in Steam and some browsers via the gamepad API.

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.

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.

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 :

Left Stick:
Vertical: 1204
Horizontal: 1203

Right Stick:
Vertical: 1206
Horizontal: 1205

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:
https://github.com/hebriel/dolphin/blob/8b776a11bacbd613688e33049ce087e5f2ec79cf/Source/Core/InputCommon/ControllerInterface/OSX/OSXJoystick.mm#L82-L83

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:
https://github.com/dolphin-emu/dolphin/blob/d39555919d39357b49a7eb02f2d96b9a71bf128b/Source/Core/InputCommon/ControllerInterface/OSX/OSXJoystick.mm#L73-L74

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.

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.

Billiard26 wrote:

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.

I suggest you build dolphin with SDL support.

cmake .. -DENABLE_SDL=1

And see if using SDL solves your problems.

Billiard26 wrote:

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.

Are you choosing the SDL interface for your device in the controller configuration?

And are you attempting to re-map all of your buttons/sticks?

Billiard26 wrote:

Are you choosing the SDL interface for your device in the controller configuration?

And are you attempting to re-map all of your buttons/sticks?

New fresh build, SDL, remapped everything, the problem is still present.

Well.. does your controller work in any applications (in macOS)? Something with code to peek at?

Billiard26 wrote:

Well.. does your controller work in any applications (in macOS)? Something with code to peek at?

Dolphin before version 9795, OpenEmu (obj-c)

values also make sense when using this library : https://github.com/suzukiplan/gamepad-osx

Wait, my fault, everything works. Human error, mea culpa. Woopsie. SDL interface works!

(So will the macOS builds use SDL by default in the future ? If yes, will the broken IOKit code still remain somewhere ?)