Bloopair: using Switch and PlayStation controllers on a Wii U

It patches IOS-PAD in memory rather than replacing the driver

Bloopair allows connecting controllers from other consoles like native Wii U Pro Controllers on the Wii U, and the README's second sentence says how it does it: it temporarily applies patches to the IOS-PAD module responsible for Bluetooth controller connections. The How it works section fills in the detail. Bloopair patches the IOSU's IOS-PAD module in memory and makes sure any Bluetooth peripheral can be paired to the console. Once a controller is paired and connected, it converts received HID reports to the Pro Controller HID report format, which is the format padscore expects. That last part is the crux. The Wii U's input stack does not speak the Switch Pro Controller protocol, so something has to translate, and doing that inside the operating system's own input module means the game never has to know that the controller is not a Wii U Pro Controller. The word temporarily in the README's own description is doing honest work, since the patch lives in memory for the session and is gone after a reboot.

Four features, and a supported list with two caveats

The feature list is short. Connect up to 7 controllers wirelessly via Bluetooth. Rumble support. Battery levels. And button and stick remapping, with the parenthetical that this only applies to Bloopair controllers. That last qualifier is the one to notice. The README lists mapping creation under Koopair's capabilities, and the feature is a property of the controllers Bloopair itself manages, so a stock Xbox controller or a DualSense will connect and work but will not be remappable. The limit of seven controllers is a Bluetooth radio constraint rather than a design choice, and the battery level reporting is a small thing that makes a big difference in practice, since the usual failure mode of a wireless controller on a console is a flat battery discovered at the worst moment.

The supported controller list covers the Nintendo Switch Pro Controller, the Switch Joy-Con, the Nintendo Switch Online SNES and N64 controllers, the Microsoft Xbox One S and X controller, the Sony DualShock 3, the Sony DualShock 4 and the Sony DualSense. Two of those carry notes. The Xbox One entry says the latest firmware versions and all Series S and X Controllers are currently not supported due to missing Bluetooth LE support, so the caveat is both about hardware revision and about the controller line. The DualShock 3 entry points to a separate pairing section, because that controller predates Bluetooth Low Energy and has to be paired over USB first. The To-Do list reinforces the point, with support for more controllers and Bluetooth LE support both listed, and the latter annotated as unlikely, only partially supported by the Bluetooth Stack. This is a to-do list that is honest about its own ceiling.

Installing means copying two things onto the SD card

The installation is a manual copy rather than a package manager operation. You download and extract the latest .zip from the releases page. You copy the `30_bloopair.rpx` from the .zip file to the `modules/setup/` folder of your target environment on the SD Card, which the README names as `wiiu/environments/aroma/modules/setup/` for Aroma. Then you copy the `wiiu` folder from the .zip to the root of your SD Card. If you are using Aroma you can delete the `Koopair.rpx` in the `wiiu/apps` folder and use the .wuhb instead. The last line of the installation section is the important one: make sure you are using Aroma or Tiramisu, with a link to the Wii U hacks guide for setting up Aroma. The environment is a hard prerequisite, not a recommendation, because the loader runs as a setup module inside it.

Pairing is a button press, and the DualShock 3 needs USB once

The usage section is brief. Once you are booted into Aroma or Tiramisu and are in the Wii U menu, press the SYNC button on your console and controller, then wait until the controller is connected. If a controller had been paired in the past, simply turning it on again should reconnect it. The DualShock 3 is the exception, and it needs to be paired using a USB cable. You open Koopair from the Wii U menu or Homebrew Launcher and open the Controller Pairing option. You connect the DualShock 3 with a USB cable to the front or back ports of the console. The screen says Successfully paired controller! once it works, at which point you can remove the USB cable and press the PS button to connect wirelessly. Press the HOME button to exit, and the controller is ready. After that initial pairing it behaves like any other wireless Bluetooth controller.

Koopair is the Bloopair companion app, and it ships with Bloopair. Its listed capabilities are testing connected controllers, creating mappings for buttons and sticks, editing controller options, managing configuration files, and pairing DualShock 3 controllers. The configuration storage detail is in the FAQ: Bloopair loads configuration files from the `wiiu/bloopair` folder on the SD Card, and the README explains that this means configurations work across multiple environments. That is a sensible design for a tool that has to work under both Aroma and Tiramisu, since one folder on the card serves both. The FAQ also has practical troubleshooting advice, such as making sure Bloopair is running and both console and controller are in SYNC mode, and clearing controller syncs through Nintendo's own support article if a controller will not pair at all.

The tree shows three layers of patching and a loader

The project structure in the README shows how the pieces fit together:

Bloopair
├── dist            - Used for creating distributable packages.
├── ios             - Bloopair IOSU patches.
│   ├── ios_kernel  - Kernel patches used for setting up Bloopair.
│   ├── ios_pad     - Core Bloopair patches.
│   └── ios_usb     - Patches used to recover from IOS exploit done by loader.
├── koopair         - Bloopair companion app.
├── libbloopair     - Library to communicate with Bloopair IPC.
├── loader          - Setup module which loads Bloopair.
└── third_party     - Third-party content included in Bloopair.

The `ios` directory holds the patches themselves, split three ways. `ios_kernel` is the kernel patches used for setting up Bloopair, `ios_pad` is the core Bloopair patches, and `ios_usb` is the patches used to recover from the IOS exploit done by the loader. The `loader` directory is the setup module which loads Bloopair, and it is the piece whose output, `30_bloopair.rpx`, is what you copy into the environment's setup folder during installation. `libbloopair` is the library used to communicate with Bloopair over IPC, and `dist` is used for creating distributable packages. The `third_party` directory holds third-party content included in Bloopair.

Building it needs devkitPPC, devkitARM and wut

The build section lists the toolchain: devkitPPC, devkitARM and wut, the last of which is the Wii U homebrew toolchain. Koopair additionally requires wiiu-sdl2, wiiu-sdl2_gfx, wiiu-sdl2_ttf and wiiu-sdl2_image, which is the usual stack for a homebrew application with graphics, fonts and image loading. After that you run `make`, and the top-level Makefile target builds the loader and the companion app:

all: loader koopair
	@echo -e "\033[92mDone!\033[0m"

dist: all
	mkdir -p dist/wiiu/apps/Koopair/
	cp koopair/Koopair.rpx dist/wiiu/apps/Koopair/
	cp koopair/Koopair.wuhb dist/wiiu/apps/Koopair/
	cp loader/30_bloopair.rpx dist/

The Makefile also has per-component targets, `ios_kernel`, `ios_usb`, `ios_pad`, `libbloopair`, `loader` and `koopair`, plus a `clean` target, and it exports `BLOOPAIR_TOP_DIR` so the sub-makes can find each other. Debug builds, which the Makefile uses by default, set the commit hash from `git rev-parse HEAD`, which is the kind of detail that tells you the project is built by one person on their own machine.

Where Bloopair is the wrong tool, and how the official controller differs

Three limits are concrete. The first is the environment dependency. Everything starts from Aroma or Tiramisu, and the patch is applied to the running IOSU's IOS-PAD module, so on stock firmware there is no IOSU to patch and nothing to install. That is a hard ceiling rather than a setup hurdle, and it means the audience is people who have already modified their console. The second is the Bluetooth LE gap. The Xbox Series S and X controllers and the latest Xbox One firmware are listed as unsupported for exactly this reason, and the to-do list marks Bluetooth LE support as unlikely because the Bluetooth Stack only partially supports it. So a controller that depends on BLE is simply out of reach, and that is a growing share of modern gamepads. The third is the maintenance model. The controller list in the to-do is tied to what the author owns, with the FAQ saying support was added for all the controllers currently owned, and while pull requests for other controllers are welcome, a controller that needs a protocol nobody has documented is a research project rather than a patch.

The obvious alternative is to use the Wii U Pro Controller, or any other first-party or licensed controller that the console already speaks to. The difference in approach is not software at all, it is radio protocol. The Pro Controller and the Wii U's own controllers use the same Bluetooth profile the console's stack already understands, so pairing is a button press and the input path is native, with rumble and battery reporting working without translation. Bloopair exists because the console's pairing process is locked to a narrow set of devices, and because the modern controllers people actually own speak protocols the Wii U stack does not implement. The trade is that Bloopair gives you a broad hardware list at the cost of running an environment and a patch on hardware that is no longer supported by the manufacturer, while the official route keeps the console in a known state. There is no third option that avoids both, since the Wii U's input stack is what it is.

Editorial conclusion

Bloopair fits a Wii U owner with a drawer full of modern controllers who wants to use them on the console without buying more Wii U accessories, and who is already running Aroma or Tiramisu. It is the wrong choice for a retail Wii U on stock firmware, since the patch is applied to the running IOSU and needs an environment to exist at all, and the wrong choice if you need Bluetooth LE, because the Bluetooth stack support is listed as only partially available and is not going to arrive. Before you install it, check that your environment is Aroma or Tiramisu, and read the fact that Xbox Series S and X controllers are unsupported rather than assuming the Xbox One controller works.

Frequently asked questions

Official sources

1. GaryOderNichts/Bloopair on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases