RipperMoonKit v1.2.25

Controllers actually work — SDL backend per prefix

If a controller showed up in Steam and in a game's settings but did nothing when you pressed buttons, this fixes it. The cause is macOS, not Wine: macOS's GameController framework takes exclusive ownership of Xbox/PlayStation pads (UsbExclusiveOwner in ioreg), which starves Wine's default raw-HID backend — the pad enumerates (so it appears everywhere) but no input reaches the game. It affects USB and Bluetooth alike and is independent of Steam Input.

Fix

RipperMoonKit now enables Wine's SDL controller backend (winebus Enable SDL) per prefix, which reads the pad through that same macOS framework cooperatively, so input flows to games.

• Applied automatically the first time a prefix launches, and after wineboot on prefix init (marker-guarded, once per prefix). It loads when the prefix's Steam/Wine next starts.
• Gated by GPTK_CONTROLLER_SDL (default 1); set to 0 in ~/.rippermoon-gptk.env to opt out.

Notes

• To apply it to a prefix that's already running, close Steam/the game so the Wine driver reloads, then launch again.
• A controller that works through Steam Input but not natively is a separate, game-specific issue.
• See docs/steam.md → "Controllers don't respond in games."