Post not yet marked as solved
I do not believe Firefox, Google Chrome, or other Chromium-based browsers use the native macOS Game Controller framework. As such these browsers must add support for gamepads individually, and Nintendo controllers are popular enough that they get supported by all.
If you are running macOS Sonoma, you can try turning on the 'Increase controller compatibility' option for your 8BitDo Ultimate 2.4G Wireless Controller. Open the system Settings app, navigate to the Game Controller settings, click on your 8BitDo Ultimate 2.4G Wireless Controller in the list, use the (+) button at the bottom of the left column to add app-specific customizations for Firefox/Chrome, and toggle ON the 'Increase controller compatibility' switch. This will result in the 8BitDo Ultimate 2.4G Wireless Controller appearing as an Xbox controller to Firefox/Chrome, if Firefox/Chrome support Xbox controllers.
Post not yet marked as solved
such as Construct 3, a browser-based game development software.
Does the Construct 3 preview mode operate entirely within a web browser? If so, which web browser are you using to run the preview mode?
If I open the first search result for 'gamepad tester' in Safari, it immediately detects my 8BitDo Ultimate 2.4G Wireless Controller connected via USB-C (tested on Sonoma 14.4). This is expected because Safari supports any gamepad that is supported by the native macOS Game Controller framework, which includes the 8BitDo Ultimate 2.4G Wireless Controller.
Post not yet marked as solved
You can not open a user client for an IOHIDInterface. You should instead locate the io_service_t for the IOHIDDevice service (the provider of the IOHIDInterface) and open a user client on it. For HID devices, our recommendation is to use the IOHIDDevice APIs rather than the lower level IOKit userspace primitives (like IOServiceOpen).
Post not yet marked as solved
There are a couple of issues here to untangle:
First is why the watchdog was triggered. It's possible that your application's main thread became blocked. We would need to see the full crash report to tell.
Second is why the application crashed during watchdog-induced exit. The answer can be found in here in your backtrace:
7 UIKitCore 0x00000001b55b9ae8 -[UIWindow _setHidden:forced:] + 104 (UIWindow.m:2556)
8 SDL2 0x00000001026ccb6c 0x102660000 + 445292
9 SDL2 0x0000000102713828 SDL_DestroyWindow + 164
10 My App 0x0000000102073890 cleanup + 60 (init.c:129)
11 libsystem_c.dylib 0x0000000186ddcfa8 __cxa_finalize_ranges + 492 (atexit.c:292)
12 libsystem_c.dylib 0x0000000186ddcd20 exit + 44 (exit.c:78)
Your code previously registered an atexit() handler. Your handler is calling SDL functions which are attempting to manipulate UIKit state. However UIKit state may only be manipulated from the main thread (unless specific APIs are documented otherwise). Handlers registered with atexit() are invoked on the thread that calls exit, which in this case was not the main thread.
The PlayStation controller specific features (touchpad, adaptive triggers) are not currently exposed through the GCControllerLiveInput collection of APIs at this time. Continue to use GCPhysicalInputProfile to access the touchpad input on DualSense and DualShock gamepads.
Are you certain that the arrayController property on the AppDelegate reads/writes from/to the _arrayController instance variable? Does your AppDelegate contain a custom implementation of -setArrayController:? Does it still fail if you explicitly synthesize the property: @synthesize arrayController = _arrayController;?
Is the arrayController property declared strong or weak?
Post not yet marked as solved
The crash report points to -[NSControl _setWindow:] as the location of the crash. Specifically, the implementation of -[NSControl _setWindow:] calls self.window to get the current window, and then calls self.currentEditor to get the current field editor. The crash is occurring on the call to self.currentEditor. Because the immediately prior call to self.window did not crash, this suggests:
A race condition. The NSControl was deallocated on a background thread between the calls to self.window and self.currentEditor.
The crash actually occurred further down (up) the stack from -[NSControl _setWindow:], but part of the backtrace was truncated. Typically we would expect to see objc_msgSend at the top of the stack trace when a crash occurs due to messaging a deallocated object. The _sigtramp in the stack trace suggests that some code in your app process was trying to handle the SIGSEGV signal - either code you wrote, or a third party crash reporter package.
Post not yet marked as solved
Can you elaborate more on why you need to develop a custom driver for this device? Is it not compliant with the USB Mass Storage Class?
One solution is for your DEXT to match on the IOUSBHostDevice instead. From the IOUSBHostDevice provider, your driver can still access the USB interfaces, endpoints, etc. But the IOUSBHostInterface nubs remain available for matching by Apple KEXTs.
Post not yet marked as solved
The full crash report would be helpful here. At first glance, it doesn't look like KVO is directly involved in this crash - I'd expect the top of the stack trace to be closer to _NSKVOPerformWithDeallocatingObservable if it were. I suspect bad memory management of the NSControl in frame 2 or an object associated with that NSControl.
Next step would be to run your app under the Zombies Instrument or Address Sanitizer. Sometimes those environments can tease out a memory management crash that is otherwise difficult to reproduce.
And does the note "PC register does not match crashing frame" tell me anything?
Does your application include a 3rd party crash reporter?
Post not yet marked as solved
Hi JESP
Please submit a feedback report with relevant details about the gamepad (*) by navigating to feedbackassistant.apple.com in your browser, or using the Feedback Assistant app on your Mac or iOS device. Create a new feedback report. Select the 'Developer Technologies & SDKs' area, and choose 'Game Controller Framework' from the technology menu, so that your feedback is routed to my team. After you create the feedback report you will receive a feedback identifier, please post that here for reference. I will followup via your feedback report.
(*) Note, please do not share confidential business information with Apple in your feedback report.
Post not yet marked as solved
Adding to previous response: Please submit the feedback to the Game Controller Framework category in the Developer SDK feedback area, so that your feedback is routed to my team. Thanks!
Game Mode on macOS Sonoma prioritizes the performance of games for smoother, more consistent frame rates and improved in-game responsiveness. The OS uses the LSApplicationCategoryType to determine whether an app is a game. Game mode activates when a game is full screen, and is the front most app.
Game Mode is intended for games, which need sustained priority access to CPU, GPU, and input peripherals in order to meet soft real-time constraints. Game Mode is not appropriate for other categories of applications, such as 3D productivity software or offline 3D rendering software, which does not have a real time constraint. The LSApplicationCategoryType should be set to the category that best reflects the intended use of your application.
Post not yet marked as solved
Hi CuriousAsking123
The GCVirtualController class is available from Objective-C. Here is a code snippet showing how to set it up.
#import <GameController/GameController.h>
// Assumes your class declares an instance variable named '_virtualController' with type GCVirtualController*
GCVirtualControllerConfiguration *configuration = [GCVirtualControllerConfiguration new];
configuration.elements = [NSSet setWithArray:@[
GCInputButtonA,
GCInputButtonB,
GCInputButtonX,
GCInputButtonY,
GCInputLeftShoulder,
GCInputLeftTrigger,
GCInputRightShoulder,
GCInputRightTrigger,
GCInputDirectionPad,
GCInputRightThumbstick
]];
_virtualController = [GCVirtualController virtualControllerWithConfiguration:configuration];
[_virtualController connectWithReplyHandler:^(NSError *error) {
if (error) { NSLog(@"%@", error); }
}];
Post not yet marked as solved
Hi Izhido_XR
I checked the code and this is currently expected in the simulator. You should see equivalent behavior in iOS, iPadOS, or tvOS simulators. On real hardware, events for the buttons you listed will be sent to your app.
Please file a feedback issue against the Simulator, requesting Simulator support those buttons. Post the feedback ID here for reference.
Post not yet marked as solved
Hi kodywu
Please submit a feedback report detailing your findings. Include the models of external keyboards and MacBook Pro built-in keyboards you observed the issue on. For external keyboards, you can find the model information on the bottom in small print. For MacBook Pro(s), you can find the model information in the Apple > About This Mac menu. If possible, connect the external keyboard(s) to the Mac prior to opening Feedback Assistant. This will allow Feedback Assistant to gather additional information about those keyboards.
Please post the feedback ID here.
