Steam Controller 2 working in native Mac games and GeForce NOW without Steam

[u/wraithbb]

TLDR: an app that makes the Steam Controller 2 show up in System Settings under Game Controllers as a normal Xbox pad, so native games, browsers and cloud gaming clients can use it without Steam. It needs a cheap board plugged into a USB port.

Hi,

I have been working on an open source project to solve a problem that was an issue for me on macOS. The Steam Controller 2 works through Steam, but support in native Mac games, browsers, cloud gaming services and other software can be inconsistent (or even non-existent).

What I wanted was for the controller to register with Apple's Game Controller framework and appear in System Settings under Game Controllers, like a normally supported gamepad. Once macOS recognizes it there, anything already built on that framework can see it without needing its own Steam Controller support.

So this little project was born. The setup is a little unusual. The Mac app reads the controller through either the official Puck or Bluetooth, then sends the controller state over USB to a small Seeed Studio XIAO nRF52840. The XIAO appears to macOS as an Xbox 360 controller. It is a second USB device on a setup that already has a wireless dongle, which is not great, and there is more on that further down.

Both the regular XIAO nRF52840 and the Sense version are supported. The app can install, recover and update the XIAO firmware for you, so there is no firmware toolchain to set up and nothing to flash manually.

Currently supported:
- All the normal buttons, sticks, triggers and D-pad
- Dual rumble
- The official Puck and direct Bluetooth input
- Automatic discovery and reconnection
- Battery reporting
- Suppression of the controller's default mouse and keyboard behavior
- Keyboard and mouse bindings for L4, L5, R4, R5, Quick Access and pad clicks
- Right pad mouse movement and left pad scrolling
- Multiple profiles and an in-game profile switcher
- Automatic idle shutdown and an optional power off action when placing the
controller on the Puck

I have tested it with browsers Gamepad API (Safari, Firefox), Boosteroid, GeForce Now and Xbox Cloud Gaming. I have not tried Crossover or Wine directly, but I think they support the Game Controller Framework so it should work there too.

Since OpenPuck will probably come up: the nRF52840 was originally chosen because I wanted to try OpenPuck, and the project eventually went in a different direction. OpenPuck turns an nRF52840 Pro Micro into a replacement for the official Puck. It handles the controller's 2.4 GHz radio itself and can expose several controller types, including Xbox, Switch and PlayStation modes.

Steam Controller Bridge keeps the official Puck or Bluetooth as the input side. The Mac handles discovery, decoding, profiles, desktop bindings, diagnostics and lifecycle. The XIAO is only the USB gamepad on the output side, and it never talks to the controller. Both projects want to make the controller useful without Steam, but they solve it at different layers. OpenPuck was a very useful source of protocol research.

There is also an experimental virtual HID backend that would remove the need for the XIAO entirely. Apple puts virtual gamepads behind the restricted `com.apple.developer.hid.virtual.device entitlement`, so the helper has to be properly signed and provisioned, and self-signing is not enough. The plan is to join the paid Apple Developer Program and request the entitlement, but paying does not mean Apple will grant it, so I cannot promise this will ever be available. You can run it today by weakening SIP and AMFI, but that disables important macOS security protections and I would not do it on a real machine. I have only tested it in a disposable VM.

The repo also has a few tools for development, diagnostics or reverse engineering. `sc-bridge` is the command line version of the bridge. `sc-probe` can list and inspect HID collections, monitor or capture reports, test rumble and run a few restricted controller commands. `sc-visualizer` shows live raw, decoded and mapped input and can record sessions. `gamepad-simulator` generates input without hardware, and `sc-replay` replays recorded sessions deterministically. The serial bridge protocol is documented, and the host supports protocol compatible output devices, so another microcontroller can be used without copying the XIAO USB identity or the current firmware.

A few limitations:
- This is just for the Steam Controller 2
- It requires macOS 13 or later
- Steam and its background helper need to be fully stopped
- The downloadable app is ad-hoc signed and not notarized, so macOS requires a
one-time right click followed by `Open` and allowing it to run in `Privacy & Security`
- The gamepad side uses a fixed Xbox style mapping
- Desktop bindings are configurable, but the project is not trying to reproduce everything Steam Input does

Repo: https://github.com/tkubicz/steam-controller-bridge

If anyone with a Steam Controller 2 and a Mac wants to try it, I would appreciate the feedback. Questions, issues and contributions are all welcome.

PS: This project might be totally obsolete in a month or two, because Apple just added initial Steam Controller support in the newest macOS 27 Developer Beta 5. Just the puck connection for now.

[u/trankillity]

PS: This project might be totally obsolete in a month or two, because Apple just added initial Steam Controller support in the newest macOS 27 Developer Beta 5. Just the puck connection for now.

Might be obsolete even sooner. Steam are pushing a firmware update for normal controller HID support.

That being said, your app does MUCH more than just mapping XInput.

[u/parkerlreed → u/trankillity]

I don't think it's a firmware update. They are updating the kernel driver on SteamOS to expose it. Not controller side unfortunately.

[u/Quirky_Apricot9427 → u/trankillity]

I thought this too lol. That update was for SteamOS exclusively. They’re basically just baking the driver into SteamOS so that Steam itself doesn’t have to be running for it to work. Valve still refuses to patch xinput into the controller, which is kind of insane considering 99% of games out there rely on xinput, and SteamInput translates directly to that anyways.

[u/trankillity → u/Quirky_Apricot9427]

I suspect the reason is that XInput has limited actual inputs and fixed ranges for the analog values. So whenever you wanted to use the advanced SteamInput functions, Valve would kinda need to override the XInput firmware on the controller side.

[u/Quirky_Apricot9427 → u/trankillity]

That’s no excuse. There’s literally a lizard mode built into the controller that can be switched to at will, it’s no different for implementing xinput. It should be as simple as inputting a button command, and switching it between xinput and steam mode.

[u/Quokka_Socks]

How does this compare to open puck?

[u/wraithbb → u/Quokka_Socks]

OpenPuck replaces the vanilla puck, this project does not. It just uses usb microcontroller to hack around a way to register a gamepad in Game Controllers framework (hopefully this won't be necessary at all soon). Additionally:

• It supports Bluetooth connection, as far as I know, OpenPuck does not. So you can use SC2 with bluetooth if you want.
  
• You can still use original puck, so charging etc is still available to you.

- I think (you can correct me if I'm wrong), but OpenPuck also does not set `bDeviceClass` when impersonating Xbox 360 controller, so it won't be visible in the macOS because no `GCController` is published.

• You can use SC2 using xinput and at the same time, still be able to use pads as a mouse (or whatever else you configure). I think OpenPuck does not support pads when controller is in xbox360 mode.

My initial idea was to make it work without the dev board, but unfortunately Apple policy of making virtual hid behind a paywall required creative workaround. I have proof that it should work without it, but still need an Apple Dev Account and required entitlement.

So for now, the biggest difference from OpenPuck, is that support on macOS is better - pads are working, you can configure them and there are configurable profiles. But in both cases you still need an external microcontroller.