Skip to content
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

Merged
merged 1 commit into from Jun 3, 2021

Conversation

pbhogan
Copy link
Contributor

@pbhogan pbhogan commented May 27, 2021

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.

@icculus icculus added this to the 2.0.16 milestone May 28, 2021
@icculus
Copy link
Collaborator

icculus commented May 28, 2021

This looks fine to me, but tossing this to @slouken to look at first, just in case.

@slouken
Copy link
Collaborator

slouken commented Jun 1, 2021

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.

@pbhogan
Copy link
Contributor Author

pbhogan commented Jun 2, 2021

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?

@slime73
Copy link
Contributor

slime73 commented Jun 2, 2021

It sounds like SDL's Hint APIs might be a good place for letting SDL users decide which backend to prefer?

@pbhogan
Copy link
Contributor Author

pbhogan commented Jun 3, 2021

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:

  1. Use Game Controller, have HIDAPI ignore devices supported by Game Controller
  2. Disable Game Controller entirely.
  3. Use Game Controller, but have it ignore devices supported by HIDAPI.

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 gamecontrollerd which presumably handles supported devices whether the API is used or not. The API probably just communicates with this 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.

@slouken
Copy link
Collaborator

slouken commented Jun 3, 2021

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.

Fair enough. Apple does tend to be aggressive in requiring use of their frameworks, so this is probably the right way to go.

Thanks!

@slouken slouken merged commit 28da6c5 into libsdl-org:main Jun 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants