Switching macOS gamepad to GCContoller

[user-none]

I started looking at adding vibrate support to macOS (#2014) and it links to the Force Feedback Framework that is in SDL. The problem with using this framework is that it doesn't support a lot of modern controllers. I attempted it with a PS4 controller and FFIsForceFeedback returned not supported.

The ForceFeedback framework is an older API and has been supplanted by the GCContoller API. This is currently being used by iOS. I have this working with macOS (not pretty just testing it out) and vibration does work. The iOS and macOS code for GCContoller is identical and can be shared between the two platforms.

So, my questions are.

1. Is it worthwhile to switch macOS to use GCContoller? Any reason not to?
2. iOS is using GCContoller using cgo instead of purego. Is there a reason for this or is it worth reworking it to purego?

[hajimehoshi]

macOS's gamepad implementation is based on GLFW, while iOS based on other libs like SDL. There is no strong reason to stick to GLFW's implementation. We can switch the implementation if we want.

[user-none]

Circling back to this now that we have the rumble part in place for iOS.

One todo item is looking at switching from Cgo to purego for the implementation. This should be straight forward to look at so I'm not concerned about it.

The other item is fallback from GCController to IOKit because GC doesn't support as many devices as we can with IOK. Specifically, older gamepads. I don't think automatic fallback can be supported if not detected as GC supported. Reasons I don't think this is possible.

1. There is no way to cross reference an IOK object to a GC object. GC doesn't provide the underlying reference id / object that we need. The best I can see is guessing using the SDL name which is going to have problems.
2. Both GC and IOK are event based and register a handler for on connect. These would conflict with each other. I don't know how events are delivered when both are listening and there isn't any documentation I can find about it. If it's random or if IOK is first then we we'd have to delay before fully accepting the gamepad with IOK to check if it's a GC.
3. I don't think it's possible to release an object from one other the other. I have to disconnect and reconnect my gamepad when I try to switch between the two implementations. This is required even with closing the app. Test:
   a. Edit code to use GC (macOS) or use iOS app on macOS (both exhibit the same behavior)
   b. Connect gamepad to test app
   c. close app
   d. Edit code back to IOK (macOS) or use a macOS app that's setup with ebitengine with IOK
   e. Gamepad will connect to test app but input does not work
   f. Redoing steps a and b the gamepad will works properly

Number 3 alone makes internal fallback not viable.

It looks like the only option is to pick one to be the default and have an env or other type of indicator that tells ebitengine to use one or the other at run time. Or decide to ditch IOK altogether and only support GC on macOS.

[hajimehoshi]

I agree picking one as the default and choose the other by an environment variable seems the way to go. Let's use GC as the default and IOKit as the legacy option.

I propose an environment variable EBITENGINE_DARWIN_GAMEPAD, which can take these values

• empty (default) or gamecontroller: use GameController
• iokit: use IOKit
  • Or hid? I now think iokit sounds better but am not 100% sure

By the way, the current file name for IOKit is *_hid_darwin.go, but probably these should be *_iokit_darwin.go, if we choose a variable value iokit instead of hid.

[user-none]

EBITENGINE_DARWIN_GAMEPAD sounds good.

I think we should switch from hid to iokit. GameController and IOKit are the two frameworks being used to drive controller support. Whereas hid is describes classes within the IOKit framework. For consistency we should use either the framework names or class representations. My vote is gamecontroller and iokit because I think they sound better too.

[hajimehoshi]

OK let's go with gamecontroller and iokit!

[user-none]

@hajimehoshi I see you're doing a lot of refactoring right now. Let me know when you're done and what you'd like me to work on for this. Also, I have a mac, so if you don't, and need me to test anything I can.

[hajimehoshi]

The refactoring is done right now. Thank you for your patience.

I also have MacBook Pro and iOS devices, so that's fine, thanks!