Cemu is where BetterJoy started — the program’s executable is still literally named BetterJoyForCemu.exe — but the honest starting point for a 2026 guide is this: current Cemu can read a Switch controller’s motion natively, so BetterJoy is now one of two routes, not a requirement. This page walks through both, gives the full BetterJoy setup for Cemu 2.6, and tells you plainly when each route is the better choice. Grab the verified package from the BetterJoy download page first if you are going the BetterJoy route.
Route A: Cemu’s native SDL motion (try this first)
Cemu 2.6 — the current numbered stable release — can take motion straight from the controller through SDL. In Input Settings, choose the SDLController API, select your Pro Controller or Joy-Cons, map the buttons, and enable the “Use motion” option. That is the whole setup: no background program, no virtual driver, no second motion path to go wrong. Two practical notes from the community guides that document this flow: pair the controller with Windows first so SDL can see it, and keep Steam Input out of the way — if Steam is also translating the controller, Cemu may see a phantom pad instead of the real one (the conflict pattern is dissected in our BetterJoy with Steam guide).
Route B: BetterJoy + the DSU/Cemuhook motion server
BetterJoy’s classic arrangement splits the job: buttons travel through its virtual XInput controller, while motion travels separately over its built-in Cemuhook/DSU server, which Cemu connects to as a client. Set it up like this:
- Install ViGEmBus (bundled MSI or the 1.22.0 final release) and reboot.
- Pair the controller with Windows over Bluetooth, or connect it by USB.
- Run
BetterJoyForCemu.exeand confirm your controller appears in its window. Leave BetterJoy running — closing it stops both the virtual controller and the motion server. - In Cemu’s Input Settings, set the controller API for buttons to XInput and select BetterJoy’s virtual controller, then map your buttons.
- Under GamePad motion source, add the DSU client pointing at 127.0.0.1, port 26760 — BetterJoy’s default server address — and select the controller slot that lights up when you move the pad.
- Set rumble strength to about 70–80% in Cemu, as the project README recommends, if you want vibration without the harsh edge some users report at full strength.
If buttons work but the motion source stays empty or gyro never responds, do not reinstall at random — the ordered checks (server line, address, slot, reset) are in the gyro-not-working fix, built from the project’s wiki and issue #671, where exactly this symptom was chased down.
Which route wins, honestly
| Situation | Better route | Why |
|---|---|---|
| Pro Controller, standard setup, everything detects cleanly | Native SDL | Fewest moving parts; nothing extra running in the background |
| SDL does not see your controller, or motion is missing/jittery there | BetterJoy DSU | A second, independent motion path with its own server and diagnostics |
| Two Joy-Cons, and you care which hand supplies gyro | BetterJoy DSU | Each Joy-Con exposes all buttons; picking one in the motion source chooses your gyro hand |
| You already run BetterJoy for other programs | BetterJoy DSU | One tool feeds Cemu and everything else — see the emulators hub |
| Old Cemuhook-era configuration you are migrating | BetterJoy DSU | Same server address and model your old setup used |
One rule whichever route you pick: use one motion path at a time. Enabling SDL “Use motion” while BetterJoy’s server also feeds the same controller invites doubled or conflicting input — the same class of problem as the double-input pattern fixed in our troubleshooting cluster. And a footnote on expectations: BetterJoy passes motion data; it does not reproduce Nintendo’s HD Rumble waveforms — you get rumble, adjustable in strength, not the original effect fidelity.
Before you blame the route: three checks both setups share
Whichever route you chose, a dead controller in Cemu is usually not a route problem at all. First, pairing: the controller must be connected to Windows before either program looks for it — if it is not paired, neither SDL nor BetterJoy can invent it, and the fix sequence starts with Windows, not Cemu. Second, exclusivity: close other translators (Steam, DS4Windows, a second BetterJoy instance) while you test, because each one can hide or duplicate the pad. Third, order: start the background pieces before the emulator — BetterJoy first in the DSU route — and restart Cemu after changing anything about the controller chain. Only once those three are clean does a failure actually tell you something about the route itself, and at that point switching routes is a legitimate diagnostic: a pad that works through DSU but not SDL (or the reverse) has told you exactly which layer to go and fix.
FAQ
Do I still need Cemuhook as a separate install with Cemu 2.6?
Current Cemu builds expose the DSU client inside Input Settings (the GamePad motion source), so the modern BetterJoy setup points Cemu at 127.0.0.1:26760 directly. “Cemuhook” survives in the vocabulary because the protocol and server model come from that era.
BetterJoy shows my controller, but Cemu’s motion source list is empty. Why?
Almost always one of three things: BetterJoy was started after Cemu (restart Cemu), the DSU client address or port is mistyped (it must be 127.0.0.1 and 26760), or the slot is not selected. The full sequence is in the gyro fix linked above.
Can I use Joy-Cons with Cemu through BetterJoy?
Yes — pair both, join or split them in BetterJoy as you prefer (see using Joy-Cons as one controller), and in the motion source pick which Joy-Con provides gyro. For native SDL, which hand supplies motion in a paired setup is not something Cemu’s documentation specifies, so test it rather than trusting a guide that states it flatly.