New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have HIDAPI skip MFI supported HID devices on macOS to avoid duplicate devices #4402
Conversation
This looks fine to me, but tossing this to @slouken to look at first, just in case. |
I think it's the other way around. If we have raw HID support for a device, that should be used instead of the MFi code, since it will normally be higher performance and have better support for device features. See the check in RAWINPUT_AddDevice() for an example of this. However, I haven't looked to see what macOS does if an application tries to send raw reports if the device is being used by the game controller kit in another application. |
The problem is that for any game released on Apple Arcade (and probably the Mac App Store at large at some point) Apple is mandating that the Game Controller framework be used. macOS doesn't have controller remapping parity with iOS yet, but it likely will get it at some point and that's a feature they require published games to support along with showing the appropriate remapped SFSymbols icons for controls. I have a future pull request coming for the latter functionality once I test it a bit more thoroughly. The bottom line is, however this is implemented, there has to be a way to say use the Game Controller framework and have HIDAPI ignore Game Controller framework supported controllers. There could also be a configuration to do the opposite, but that would get a bit more complicated. I think the only controllers supported by Game Controller that has no HIDAPI implementation on macOS are Xbox controllers: the white Xbox One, the Xbox Elite 2 and the Xbox Series X controllers. Incidentally, I don't think there is any way to support Xbox controllers outside the Game Controller framework right now. The old 360Controller driver is defunct as of macOS 11. Anyway, maybe use this pull request as a baseline (after all, using the platform's built-in support is a sensible default and they're consistently adding new controllers) and then work on adding a configurable alternative that favors HIDAPI implementations? |
It sounds like SDL's Hint APIs might be a good place for letting SDL users decide which backend to prefer? |
Yes, I'd say having a hint setting to disable using the Game Controller framework would be a good way to go. I suppose there's really three settings:
I think option 1 should be the default. Performance seems to be decent and pretty much all device features are supported. Apple is doing a fairly good job of adding to this framework, at least for now. It's even documented—hah. Option 2 should be easy, although I think there are things happening on the OS level we can't disable. There's a system daemon Option 3 is a bit more tricky and may have unintended side effects as Sam mentioned. I'm not sure if there's an easy way to know if a device in Game Controller is implemented in HIDAPI. Game Controller does not provide vendor/product IDs for comparison. Currently the list of Game Controller supported devices is small enough that we could probably just guess correctly, but as the list grows it might become cumbersome to maintain and can vary with each macOS version/update. |
Fair enough. Apple does tend to be aggressive in requiring use of their frameworks, so this is probably the right way to go. Thanks! |
HIDAPI needs to ignore devices supported by Apple's Game Controller framework in the same way IOKit joystick does to avoid duplicate devices.
There's probably a few ways to handle this, but this seems to be the simplest patch to make.