Why BetterJoy is Windows-only by construction

BetterJoy is not a cross-platform app that merely skipped other systems. Its core tricks are Windows-specific: it creates virtual Xbox/DS4 controllers through ViGEmBus, a Windows kernel driver, and manages device visibility through a Windows HID driver lineage (HIDGuardian in v7.1; the modern successor is HidHide). Neither layer exists on macOS, Linux, or Android, so there is nothing to “port” short of rewriting the program against each system’s own controller stack — work nobody has done, in a project whose last release was November 2021. Manage expectations accordingly: this will not change with a future update, because there is no update pipeline. On Windows itself, the verified package is on our download page; everywhere else, read on.

macOS: Bluetooth pairing plus native readers

On a Mac, the working pattern is to pair the Pro Controller or Joy-Cons in the system’s Bluetooth settings and let each program read the pad through its own input stack. Two verified pillars cover most needs. Steam Input runs on macOS and translates Switch controllers inside Steam games (Valve added Pro Controller support in 2018 and Joy-Con — individually and paired — in 2022). And Dolphin, which ships a macOS build, maps Switch controller motion directly through SDL in its current releases, no server required — the details are in our Dolphin guide. Azahar (the 3DS emulator) also ships a macOS build; as we detail in the Azahar guide, its Switch-controller motion story is not officially documented, so test rather than assume. What macOS does not have is a BetterJoy-style system-wide XInput layer or DSU server — setups designed around those are Windows designs.

Linux: the kernel already speaks Joy-Con

Linux is, ironically, the non-Windows platform where Switch controllers are most at home — through the operating system rather than any BetterJoy equivalent. As general guidance: the mainline kernel’s hid-nintendo driver handles Joy-Cons and the Pro Controller as standard input devices, and the joycond daemon can combine a Joy-Con pair into a single pad, the same trick BetterJoy performs on Windows. On top of that foundation, Steam Input works on Linux exactly as described above, and emulators read the controllers through SDL — Dolphin’s Linux Flatpak build maps motion natively, and Cemu and Azahar both publish Linux builds whose native input paths are the ones to use. The one BetterJoy feature with no direct Linux counterpart in this stack is the Cemuhook/DSU server feeding multiple programs at once; on Linux, plan per-emulator instead.

Android: the emulator reads the pad, not a driver

Android has no driver layer for a program like BetterJoy to plug into, and none exists. The real route: pair the controller in Android’s Bluetooth settings, then use it inside apps that read gamepads through Android’s own input system. Dolphin and Azahar both ship Android builds and handle controllers that way — buttons and, where the app implements it, motion from the pad the OS paired. Anything beyond that — an “Android BetterJoy” promising system-wide XInput — does not exist as a real product, whatever the download page claims. Be particularly careful here: fake-APK pages are a standard malware costume, and the BetterJoy name is exactly the kind they wear.

Steam Deck counts as Linux here

A frequent follow-up: the Steam Deck runs SteamOS, a Linux system, so everything in the Linux row applies to it. BetterJoy does not run on SteamOS; what the Deck offers instead is Steam Input itself — Valve’s own translation layer, running on Valve’s own hardware — plus the native SDL input of the emulators you install there. For Switch controllers on a Deck, that combination is not a consolation prize; it is the intended path, and it covers Pro Controllers and Joy-Cons (paired or single) inside Steam’s controller settings.

The honest summary

FAQ

I found a site offering “BetterJoy for Mac”. Is it real?

No. BetterJoy’s only official distribution is the Windows release on its GitHub project page. A “Mac version” is at best a different program borrowing the name and at worst a malicious installer — either way it is not BetterJoy, and it cannot give you the Windows program’s behaviour.

Can I run BetterJoy in a Windows virtual machine on my Mac or Linux PC?

As general guidance: the program itself can run in a VM, but its job involves Bluetooth devices and kernel drivers, and passing a Bluetooth controller through to a guest OS reliably is the hard part that varies by setup. Most users find the native routes on this page simpler and more robust than fighting VM device passthrough.

Will the maintained BetterJoy fork change this?

The community fork continues the same Windows program — same driver model, same platform. Nothing in its published changes suggests a macOS, Linux, or Android port, and we would not expect one: the Windows-only design is the program’s foundation, not an oversight.

The successor landscape, verified

• Eden — founded in mid-2025 by former Citron developers, based on Yuzu and GPLv3-licensed, developed on its own infrastructure (git.eden-emu.dev). Its v0.2.0 release of 13 May 2026 — which we confirmed on the project’s own release page — brought firmware 22.0 compatibility and a built-in auto-updater, with builds for Windows, Linux (AppImage), Android, and macOS (experimental). This is the line we can point to without hedging.
• Citron — the original project ceased in February 2026; its website, GitHub, GitLab and Discord disappeared the same day. Reports attribute the end to internal disputes rather than a direct takedown, and a “Citron NEO” continuation is talked about — its lineage and official status are unverified, so we do not link it as a successor.
• Sudachi — its developer announced the project stopped; its last update was 2 July 2025, and he pointed users toward Eden.
• The rest — a long tail of forks (Suyu and others) plus the February 2026 Nintendo DMCA wave that named thirteen Switch-emulator projects at once. Anything in this tier should be treated as unmaintained or unverifiable until its own repository proves otherwise.

The pattern these statuses teach: in this scene, “successor” claims are cheap and releases are the evidence. It is the same discipline we apply on the Ryujinx successors page — the other Switch-emulator family, with its own separate lineage and its own BetterJoy story.

What BetterJoy does — and does not — add here

Start with why BetterJoy is not a prerequisite: a Switch emulator’s entire purpose includes emulating Switch controllers, so Eden reads a Pro Controller’s or Joy-Cons’ buttons and single-controller motion through its own input stack. You do not install BetterJoy to “enable” your controller in Eden, and any guide framing it that way is selling you a step you do not need.

What BetterJoy genuinely offers is its generic output layer. It converts the physical pad into a standard virtual XInput or DS4 controller, plus a DSU motion server at 127.0.0.1:26760. Any emulator — Eden included — that can read an XInput device can read BetterJoy’s virtual one. That is useful in real situations: when the emulator’s direct reading of your specific pad is flaky, when you want the same controller configuration (remapped buttons, gyro-to-mouse, a joined Joy-Con pair per the pair guide) to apply identically across several programs, or when one BetterJoy instance feeds your whole emulator row a consistent controller. Set it up from the download page, pair the pad, run BetterJoy, and in the emulator select the virtual XInput controller as the input device.

Two disciplines keep this honest. First, one translator at a time: if Eden is reading BetterJoy’s virtual pad, do not also hand it the physical controller, or you will manufacture the double-input problem our troubleshooting cluster exists to solve. (History rhymes here: the infamous “Duplicate timestamp enqueued” flood originally surfaced when Yuzu read the wrong controller view — DirectInput instead of XInput.) Second, no per-title promises: whether a given game runs well in Eden is a question about Eden’s compatibility, which changes release by release. BetterJoy neither improves nor certifies any title’s emulation, and we will not list “supported games” for it.

A security note on “Yuzu” and “Eden” download sites

The shutdown era left behind hundreds of mirror and fan sites, and the February 2026 DMCA wave showed how contested this space still is. The practical rules: get Eden only from its own project infrastructure; treat any site offering a “Yuzu latest version” as an unofficial mirror of a program that stopped in 2024, whatever its version numbers claim; and be doubly suspicious of installers that bundle “codecs”, “updaters”, or driver packs — the real Eden is a self-contained emulator download with a built-in auto-updater since v0.2.0. The same hygiene applies to BetterJoy itself: one verified package, from the project’s GitHub, linked from our download page. In a scene where the original projects can vanish overnight, the boring discipline of downloading from the source is most of what keeps a setup safe.

FAQ

Is Eden the official Yuzu successor?

There is no “official” successor — Yuzu’s team disbanded under the settlement. Eden is the successor we can verify is actively and publicly releasing (v0.2.0, May 2026) from its own project infrastructure, which is the strongest claim anyone in this scene can honestly make.

Should I still use a Yuzu build I already have, with BetterJoy?

An archived Yuzu build will behave as it always did — BetterJoy’s XInput output works with it the same generic way. But it receives no fixes, and its input quirks (like the DirectInput reading behind the timestamp flood) are frozen with it. Eden is where the maintenance is.

Does BetterJoy fix controller issues inside Eden?

It can route around some — a pad Eden reads poorly directly may behave through the XInput layer. It cannot fix emulation-side input bugs, and stacking both input paths at once creates more problems than it solves. Try Eden’s native reading first; add BetterJoy when you have a specific reason from the list above.

From Citra to Azahar

Azahar was formed from PabloMK7’s Citra fork merged with the Lime3DS project, and shipped its first release on 22 March 2025. It runs on Windows, macOS, Linux and Android, plus a Libretro core. Its stable line, per the project’s own release page as of our October 2026 check, stands at 2126.2 (a security-fix release), with a 2127.0 alpha series in prerelease above it. If a site is still handing you a “latest Citra build” in 2026, it is handing you a dead program from an unofficial mirror — Azahar is where 3DS emulation is actually maintained, and it is the only program this page discusses.

How motion worked in the Citra era

In Citra’s architecture, 3DS games that used the console’s gyroscope needed a motion feed the emulator could not get from a plain XInput pad. The standard solution was the one BetterJoy was built around: BetterJoy read the Switch controller, supplied buttons as a virtual XInput device, and streamed gyro data from its Cemuhook/DSU server (127.0.0.1:26760), which Citra consumed as a motion source. Thousands of working setups were built exactly this way, and the muscle memory of the community — “3DS motion means BetterJoy plus a UDP server” — comes from that era. Our gyro troubleshooting page documents that server model in detail, because Cemu users rely on the same one.

What is verified about Azahar + motion — and what is not

Here is the honest ledger, because Azahar pages elsewhere tend to assert more than anyone has documented:

• Verified: Azahar descends from Citra’s codebase and inherits its general input and motion architecture. The project is actively released on the 2126.x stable line.
• Not verified: We found no statement in Azahar’s official documentation or release notes confirming native SDL gyro support for Switch controllers, and no official specification of a DSU client for it. Claims in either direction — “Azahar reads Joy-Con gyro natively now, BetterJoy is obsolete” or “Azahar requires BetterJoy for motion” — go beyond what the project’s own publications support. We will not print either as fact.

The practical consequence: treat the DSU route as the known-working path to try, not a guarantee. Set up BetterJoy from the download page, pair your controller, leave BetterJoy running so its server is live at 127.0.0.1:26760, and then check your Azahar build’s Controls settings for a motion/UDP source option pointing at that address, exactly as Citra exposed it. If your build offers it, buttons via XInput plus motion via DSU is the Citra-era arrangement and the one with a track record. If a future Azahar release documents native SDL motion, prefer it — fewer moving parts always wins, the same verdict we give for Cemu and Dolphin — and we will update this page when the project publishes it.

The cross-platform catch

Azahar runs on macOS, Linux and Android. BetterJoy does not — it is a Windows program built on Windows drivers, full stop (see BetterJoy for Mac, Linux and Android). So on those platforms there is no DSU-from-BetterJoy option at all: you are relying on whatever the emulator and the operating system can read from the controller directly. That asymmetry is worth knowing before you design a setup around one machine or another: the BetterJoy motion route exists only where Windows does.

Reading old Citra guides in the Azahar era

Most surviving setup guides were written for Citra, including the widely copied BetterJoy ones. Their architecture still maps onto Azahar — virtual XInput pad for buttons, DSU server for motion, the 127.0.0.1:26760 address — because Azahar inherited that design. What does not map reliably is the screenshots: menu names, settings layout, and where the motion source lives have all been reorganised since 2024, and the 2127 alpha line is reorganising them further. So use old guides for the model and this page for the status, but navigate by your own build’s Controls section rather than any guide’s pictures — ours included. If a setting in your build contradicts a Citra-era screenshot, your build is right.

FAQ

Is Citra still safe or legal to download from the sites offering it?

Citra was discontinued in March 2024 and its official distribution is gone. Third-party “Citra download” sites are unofficial mirrors of a dead program; the maintained, supported path is Azahar from its own project site.

Does Azahar need BetterJoy for a Switch Pro Controller?

For buttons, no — a standard controller input path handles those. For gyro in motion-controlled 3DS games, the Citra-era DSU arrangement via BetterJoy is the path with a documented track record; native Switch-controller gyro in Azahar is, as of our check, unconfirmed by the project’s own documentation.

My DSU motion option isn’t where Citra had it. What now?

Azahar’s settings evolve between releases, and the 2127 alpha line is actively changing things. Check the Controls section of your exact build and the project’s current documentation rather than a screenshot from a Citra-era guide — including ours: if the option has moved or been renamed, the principle (client pointing at 127.0.0.1:26760, BetterJoy running) still tells you what you are looking for. The full index of related guides is on the emulators hub.

Know what Steam already does

Valve’s client has supported the Switch Pro Controller natively since 2018, gyro included, and added Joy-Cons in August 2022 — both individually as mini-gamepads and combined into pairs. Inside Steam’s ecosystem that covers a lot of BetterJoy’s historical territory with zero drivers and zero background tools. Steam’s limits are scope, not quality: its translation only applies to games Steam launches or manages, and it offers no DSU/Cemuhook motion server for outside programs. BetterJoy’s remaining strengths are the mirror image: system-wide XInput or DS4 output for anything on the PC, plus the DSU server at 127.0.0.1:26760 that emulators consume. Neither tool is “better” — they own different territory, and the Platforms & Emulators hub maps that territory across programs.

Mode 1: Steam Input only (most Steam games)

If you play a Steam game with your Pro Controller or Joy-Cons and do not need a DSU motion feed, the cleanest setup is: close BetterJoy entirely and let Steam Input translate the pad. Enable Nintendo Switch controller support in Steam’s controller settings, let Steam detect the physical controller, and configure gyro there if the game uses it. With BetterJoy closed there is no virtual XInput pad competing for the game’s attention, and double input is impossible by construction. Most people who “have a BetterJoy problem in Steam games” actually have a two-translators problem, and this mode is the whole cure.

Mode 2: BetterJoy as a motion server only (emulators + Steam in the mix)

The hybrid case: you want Steam to handle your controller’s buttons — or an emulator launched through Steam to use its own input — but something still needs gyro data the BetterJoy way, via DSU. BetterJoy supports exactly this split:

1. Pair the controller and start BetterJoy from the download page package.
2. In BetterJoy’s settings, turn off XInput emulation. BetterJoy stops presenting a virtual Xbox controller, so nothing doubles.
3. Leave the application running: its UDP motion server keeps broadcasting on 127.0.0.1:26760.
4. Point your emulator’s DSU client at that address (the pattern used in our Cemu guide), while buttons come from the physical pad through Steam or the emulator’s own SDL reading.

This is also the mode the project’s own guidance points at for coexistence: motion from BetterJoy, buttons from whoever owns them — never both from both.

Mode 3: BetterJoy owns the pad (non-Steam games)

For a game outside Steam — a Game Pass title, an itch.io download, a standalone emulator — BetterJoy’s full mode is the point of the program: XInput or DS4 emulation, system-wide. The discipline is on the Steam side: quit Steam, or at minimum disable Steam Input for that controller while you play, so the client is not quietly translating the physical pad in parallel. If you skip this, you will meet the symptoms catalogued in our double input fix — including the console cousin, the “Duplicate timestamp enqueued” flood described in its own fix page, which appears when a program reads the wrong one of the two controller views.

The decision table

The per-game middle ground

You do not have to reorganise your whole library around one mode. Steam lets you toggle Steam Input per game (in the game’s properties, under Controller), which makes a practical mixed setup possible: leave Steam Input in charge for the bulk of your Steam catalogue, disable it for the one or two titles where you prefer BetterJoy’s full emulation, and quit Steam entirely for non-Steam sessions. What you cannot do is improvise per launch — double input does not announce which translator caused it, it just ruins the session. Decide the owner when you install the game, note it if you have to, and hold the line. Also note that BetterJoy’s output choice (XInput versus DS4 emulation) does not change the rule: a virtual DS4 pad and Steam’s own reading of the physical controller are still two views of one pad, and the same one-owner discipline applies.

FAQ

Why do my buttons register twice only in Steam games?

Because Steam Input reads the physical controller while the game also sees BetterJoy’s virtual one — two views of the same pad, both active. Pick an owner using the table above; no other setting needs changing.

Can Steam Input replace BetterJoy completely?

For games inside Steam, largely yes — Pro Controller support dates to 2018 and Joy-Con pairing to 2022. What Steam cannot give you is system-wide XInput/DS4 output for non-Steam programs or a DSU motion server, which is where BetterJoy remains the tool.

Does turning off XInput emulation in BetterJoy break the motion server?

No — they are separate functions. With emulation off, BetterJoy stops creating a virtual controller but keeps serving motion data over UDP, which is precisely the split Mode 2 relies on.

Two lineages — do not mix them up

Switch emulation after 2024 forks into two separate family lines, and guides that blur them mislead you:

• The Ryujinx line: Ryubing, a fork maintained after the shutdown and hosted on its own infrastructure (git.ryujinx.app). Its original maintainer, GreemDev, confirmed stepping back in February 2026, with others continuing it as a maintenance project — bug fixes and compatibility upkeep rather than new features. Its exact release cadence since then is something we could not verify from a primary source, so be sceptical of any page quoting a “latest Ryubing version” with confidence.
• The Yuzu line: Eden, a Yuzu successor founded by former Citron developers. It belongs to the other family — covered in our BetterJoy and Eden guide — and it does not inherit Ryujinx’s dual-Joy-Con caveat, because Switch emulators handle their own controller model differently.

Both lines were among the projects named in Nintendo’s February 2026 DMCA wave, which is context worth knowing when a “successor” site asks you to download something: verify what you install, and prefer the projects’ own repositories over aggregator pages. Our Platforms & Emulators hub tracks the status of each line as we verify it.

Why dual Joy-Con motion is the exception

A Switch emulator’s native input stack treats a controller as one device with one motion source — fine for a Pro Controller, and fine for a Joy-Con pair merged into a single virtual pad. But some Switch games are built around each Joy-Con as an independent motion controller: a gyro in your left hand and a separate gyro in your right, reporting separately. That is precisely the case Ryujinx’s README carves out. The emulator’s own pipeline does not split one paired connection into two independent motion streams, so the split has to happen before the data arrives — which is what a DSU server like BetterJoy does. BetterJoy talks to each Joy-Con individually, and its Cemuhook/DSU server (127.0.0.1:26760) can present each hand’s motion to the emulator as its own source. DS4Windows is named in the README as the alternative for the same job.

Everything else about the Ryujinx family is native, and we will not pretend otherwise: single-controller motion, Pro Controller play, and ordinary button input do not need BetterJoy. There is also a telling footnote in the Ryubing FAQ — users of DualShock 4/5 pads are advised not to layer BetterJoy or DS4Windows on top, because those pads work natively. That advice is about PlayStation controllers; it does not cancel the Switch dual-Joy-Con requirement, and pages quoting it as “BetterJoy is unnecessary for Ryujinx” are mixing two different statements.

The DSU setup, in principle

Menus differ between Ryujinx successors and builds, so treat this as the shape of the setup rather than a button-by-button script:

1. Get BetterJoy from the download page, install ViGEmBus, and reboot.
2. Pair both Joy-Cons with Windows individually over Bluetooth — each must appear in BetterJoy’s window. (The pairing walkthrough is in the Joy-Con connection guide; for dual-motion play you keep them as separate controllers rather than joining them into one pad.)
3. Leave BetterJoy running so its DSU server stays live on 127.0.0.1:26760.
4. In your Ryujinx successor’s input settings, configure each player’s controller and enable motion via the DSU client where the build exposes it, assigning each Joy-Con’s motion source to the corresponding player.
5. Test with a title that reads the two hands independently; if one hand’s motion is missing, re-check that both Joy-Cons are listed in BetterJoy before touching emulator settings.

Bluetooth quality matters twice here — two simultaneous Joy-Con connections are exactly the load the project wiki warns needs a decent adapter — so if one hand lags, work through the Bluetooth lag fix before blaming the emulator.

What “maintenance mode” means for your setup

Because the Ryujinx line now advances by maintenance rather than feature development, expect builds to differ in the details this setup touches: where the input settings live, whether a given build exposes a DSU client at all, and how motion sources are labelled. A successor build without a DSU client option cannot use the BetterJoy route for dual motion no matter how correctly BetterJoy itself is configured — that is a property of the build, not a fault in your setup. So the working order is: confirm your build actually offers a DSU/motion-client setting (its own documentation or settings screen is the authority), then do the BetterJoy half. Pages that print one fixed click-path for “Ryujinx” in 2026 are describing a program that no longer exists in a single canonical form.

FAQ

Is Ryujinx itself coming back?

No. The original project ended in October 2024 by agreement with Nintendo. What continues is community maintenance of its code in forks such as Ryubing — a different thing, run by different people, and worth describing as such.

Do I need BetterJoy for a Pro Controller in Ryubing?

No. Per the Ryujinx README’s own framing, motion is natively supported in most cases; the BetterJoy/DS4Windows requirement is specifically about dual-Joy-Con independent motion.

Does this also apply to Eden?

Eden is a Yuzu-lineage emulator, not a Ryujinx successor, and it is not the subject of Ryujinx’s README statement. Its input handling is its own; see the Eden guide linked above rather than applying this page’s caveat to it.

Dolphin’s official position: SDL first, DSU second

Dolphin is actively developed — the current release line is 2609 (September 2026) — and its wiki’s DSU Client page takes a clear stance. Since Dolphin 5.0-16861, a Switch controller’s motion axes can be mapped directly through SDL inside Dolphin, and the wiki states that this generally performs better than the DSU route, with lower latency, so it should be preferred. BetterJoy appears on that page as one of the alternative DSU servers for cases where the direct route does not fit. We think that ordering is correct, and this guide follows it: native first, BetterJoy when you have a reason. If you do go the BetterJoy route, the verified package is on the BetterJoy download page.

Route A: native SDL motion in Dolphin

1. Pair the Pro Controller or Joy-Cons with Windows over Bluetooth (or connect by USB).
2. In Dolphin, open Controllers and configure an emulated Wii Remote or GameCube controller.
3. Choose the SDL entry for your Switch controller as the device.
4. Map buttons and sticks, then map the motion axes from the same SDL device — Dolphin reads the gyro and accelerometer directly.
5. Test in a game with motion aiming or pointer controls and adjust sensitivity in Dolphin’s motion settings if needed.

No ViGEmBus, no background server, nothing else translating the pad. For a single Pro Controller this is the setup we recommend to most Dolphin users in 2026.

Route B: BetterJoy as Dolphin’s DSU server

BetterJoy earns its place in a Dolphin setup when SDL will not cooperate — a controller SDL does not expose cleanly, a Bluetooth stack quirk, or a rig where BetterJoy already feeds several emulators at once (see the Platforms & Emulators hub). The arrangement: BetterJoy turns the pad into a virtual XInput controller for buttons and runs its DSU server for motion; Dolphin connects as a DSU client.

1. Install ViGEmBus, pair the controller, and run BetterJoy — confirm the controller is listed in its window.
2. In Dolphin, open Controllers → Alternate Input Sources and enable the DSU client.
3. Set the server address to 127.0.0.1 and port 26760, BetterJoy’s defaults.
4. Back in controller configuration, select the DSU device/slot as the motion source for your emulated controller and map motion from it.

The conflict to avoid

Do not leave both paths live for the same pad. If Dolphin reads the physical controller through SDL and BetterJoy’s virtual XInput controller and the DSU feed, you can get doubled inputs or a controller that seems possessed — the same failure family as the one in our double input fix. Pick the device entries deliberately: in a BetterJoy setup, buttons come from the virtual controller and motion from DSU; in a native setup, everything comes from SDL. Lag complaints in this arrangement usually trace to Bluetooth, not the protocol — work through the Joy-Con Bluetooth lag fix (issue #731’s Dolphin case was solved by updating the Intel Bluetooth driver).

So, “BetterJoyForDolphin”: why the confusion persists

Three ingredients keep the myth alive. First, the filename: BetterJoyForCemu.exe looks like one of a family (“ForCemu”, so surely “ForDolphin”?). Second, the project’s original name really was BetterJoyForCemu — it was written for Cemu with Cemuhook, then grew generic XInput and DSU support, and was renamed BetterJoy in v6.1 while the .exe kept its birth name. Third, content farms happily invent edition pages for search traffic. The project’s own record is unambiguous: one repository, one release line (ending at v7.1), plus a separately maintained community fork — and its Dolphin relationship is “DSU server”, full stop. Any download labelled as a Dolphin edition is a repack of that same program, at best.

A note on Wii Remote emulation

Most Switch-controller-in-Dolphin setups exist for Wii games, where the emulated Wii Remote’s motion is the whole point — pointing, tilting, shaking. Both routes above feed the same destination: Dolphin’s Wii Remote motion inputs. The difference is only where the gyro data is translated (inside Dolphin via SDL, or in BetterJoy and shipped over DSU). GameCube titles, which never used motion, need nothing from this page at all: any route that delivers buttons and sticks — including plain SDL — is complete.

FAQ

Is BetterJoy required for motion controls in Dolphin?

No. Dolphin’s wiki recommends mapping Switch controller motion directly via SDL, which has been possible since 5.0-16861. BetterJoy is an alternative motion source, useful when the direct route misbehaves or when one server feeds several emulators.

Which is less laggy, SDL or BetterJoy’s DSU?

Dolphin’s documentation says SDL mapping generally has lower latency than DSU, because the data makes one less hop. In practice Bluetooth quality dominates both — a weak adapter will make either route feel bad.

Can I use a split Joy-Con pair in Dolphin?

Yes. Natively, Dolphin can read each Joy-Con through SDL; through BetterJoy you can also join or split them first (see using Joy-Cons as one controller) and let Dolphin see the combined virtual pad with DSU motion.

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:

1. Install ViGEmBus (bundled MSI or the 1.22.0 final release) and reboot.
2. Pair the controller with Windows over Bluetooth, or connect it by USB.
3. Run BetterJoyForCemu.exe and confirm your controller appears in its window. Leave BetterJoy running — closing it stops both the virtual controller and the motion server.
4. In Cemu’s Input Settings, set the controller API for buttons to XInput and select BetterJoy’s virtual controller, then map your buttons.
5. 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.
6. 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

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.

The setup, Windows 10 edition

Installation follows the standard path: get the verified package from the BetterJoy download page, extract it to a permanent folder, install the bundled ViGEmBus driver (the ViGEmBusSetup_x64.msi or ViGEmBusSetup_x86.msi in the Drivers folder), reboot, pair your controller over Bluetooth or plug it in by USB, then run BetterJoyForCemu.exe. Our step-by-step walkthrough of pairing itself is in the Pro Controller connection guide and the Joy-Con connection guide — the Windows 10 notes below are the parts those guides leave out.

Disconnecting properly: the README’s [Windows 10] flow

There are two ways to disconnect, and the difference matters when a controller later refuses to reconnect. For a quick disconnect, hold the Home or Capture button for about two seconds (or tap the Sync button) — the controller sleeps and will reconnect when you press a button. For a full removal — the flow the official README documents under its “[Windows 10]” heading — do this:

1. Open Settings → Devices → Bluetooth & other devices.
2. Look under the first category, “Mouse, keyboard, & pen” — the Pro Controller appears there, not under the game controller headings people expect.
3. Click the controller entry and choose Remove device.

Full removal is the right move before re-pairing a controller that Windows half-remembers, before lending the pad to a Switch again, and as step one of the not-detected fix sequence. Most “it paired yesterday and now nothing works” cases on Windows 10 end here.

Driver signing on Windows 10

64-bit Windows 10 requires kernel drivers to be signed, and the drivers BetterJoy relies on are: the ViGEmBus installers (both the MSI bundled with v7.1 and the final standalone 1.22.0 release from the nefarius project) carry valid signatures and install without any policy changes. That has a practical consequence worth stating plainly: you never need to disable driver signature enforcement, test-signing mode, or Secure Boot to install BetterJoy. Tutorials that route you through those steps are either outdated or pushing a repacked driver from an untrusted source. If a ViGEmBus install goes wrong — BetterJoy starts but reports the bus missing — the clean repair (remove, reinstall 1.22.0, reboot) is written up in the vigembusnotfoundexception fix.

Is Windows 10 still a viable BetterJoy platform?

From BetterJoy’s side, yes, completely. The project’s supported world is Windows 10 and 11: ViGEmBus 1.17 and later officially target exactly those two systems, and nothing in v7.1 depends on services that have changed on Windows 10 since release. The separate question is Windows 10’s own lifecycle — Microsoft has ended mainstream support for the OS, so a Windows 10 machine’s exposure is about Windows updates and security, not about whether your controller works. Plenty of dedicated emulation boxes run Windows 10 deliberately, offline or on extended security updates, because everything in the chain — BetterJoy, ViGEmBus, the emulators in our Platforms & Emulators hub — is stable there. That remains a rational setup; just make the decision with your eyes open about the OS itself.

One expectation to set: because BetterJoy’s own development stalled after v7.1, Windows 10 users and Windows 11 users are in the same boat — same build, same known issues, same fixes in the troubleshooting hub. Nobody is missing a newer Windows 10-specific patch, because there isn’t one for either OS.

Windows 10 quirks worth knowing

• Bluetooth adapter limits are the classic bottleneck. The project’s wiki warns that you need a decent Bluetooth adapter comfortable handling three or four connections at once — two Joy-Cons plus other devices can saturate cheap adapters. The full diagnosis is in the Joy-Con Bluetooth lag fix.
• “Using USB” stalls. If plugging the controller in appears to do nothing, the wiki’s suspects are Windows still finishing device setup and USB selective-suspend power saving — give it a moment, try another port, and disable USB power saving for the controller.
• Administrator mode is conditional. As on Windows 11, elevate BetterJoy only if keyboard or mouse mappings fail to respond; it is not a default requirement. Our Windows 11 page explains the same evidence base if you are comparing the two systems before an upgrade.

FAQ

Which ViGEmBus should a Windows 10 user install — the bundled one or 1.22.0?

Either works on Windows 10. The bundled MSI matches what v7.1 shipped with; the standalone 1.22.0 is the driver’s final release and the better choice for a fresh install or a repair. Do not stack multiple versions — one clean install, then reboot.

My controller shows under “Mouse, keyboard, & pen”. Is that wrong?

No — that is exactly where the Pro Controller appears in Windows 10’s Bluetooth settings, per the official README. It is also where you remove it for a clean re-pair.

Will BetterJoy stop working on Windows 10 now that Microsoft ended support?

Nothing in BetterJoy or ViGEmBus checks or depends on Microsoft’s support status. The software will keep running; the consideration is the security posture of an unsupported OS, which is your call to make for a gaming machine.

Why there is no official “Windows 11 supported” stamp

BetterJoy’s latest release, v7.1, dates from 22 November 2021 — weeks after Windows 11 itself launched — and the project has shipped no newer release since. Its README never gained a Windows 11 compatibility statement; the disconnect instructions in that README are still headed “[Windows 10]”, which reflects documentation that stopped being updated, not a verdict on the newer OS. Meanwhile the layers BetterJoy depends on did move with the times: ViGEmBus (the virtual gamepad bus driver) lists Windows 10/11 as its supported systems from version 1.17 onward, and its final release, 1.22.0, is a signed installer for current Windows. So the honest framing is: the author never certified Windows 11, the driver layer supports it, and the user base runs on it. If you have not installed yet, start from the BetterJoy download page so you get the verified v7.1 package and the current driver.

The evidence: issue reports through 2025–2026

The strongest signal is the project’s own issue tracker. Searching it for “Windows 11” returns around thirty threads, and they keep being filed into 2025 and 2026 — people do not file setup questions for software that flatly refuses to launch on their OS. In several threads the reporters state their system explicitly (“My OS Windows 11 x64”) while describing a workaround that got them running, including the low-battery-notification cases covered in issues #898 and #973. Issue #1222 is equally telling in the opposite direction: on Windows 11 the operating system itself recognised the reporter’s PowerA controller fine — it was BetterJoy that did not list that particular third-party model. That is a third-party support gap, not a Windows 11 failure.

Just as important is what the tracker does not show: no recurring, Windows-11-specific breakage pattern. The best-known crash report, #944 (BetterJoy crashing when “Enable Rumble” is disabled), was first reported on Windows 11 — and then reproduced on Windows 10 as well. It is a cross-version application bug, not an OS compatibility wall. One report of Bluetooth failing after a driver install (#943) was resolved by powering down and re-scanning hardware and has no generalisable Windows 11 cause. Our full fix index is the troubleshooting hub; the Windows 11 conclusion from all of this is narrow but solid: expect it to work, and expect any trouble to come from Bluetooth drivers, leftover HIDGuardian state, or third-party controllers — the same suspects as on Windows 10.

What changes when you install on Windows 11

Pairing lives in the new Settings app

The flow is the same as ever — hold the controller’s Sync button for about five seconds until the lights cycle, then pair — but the screens moved. In Windows 11 it is Settings → Bluetooth & devices → Add device → Bluetooth. Pair the Pro Controller or each Joy-Con there first; only then start BetterJoy, which picks up already-paired controllers. If the controller pairs in Settings but never appears in BetterJoy, work through the “No Joycons detected” fix sequence — run order and a stale HIDGuardian blacklist cause most of those cases, on both Windows versions.

Driver installation and signing

Install ViGEmBus from a signed source: the installer bundled in the v7.1 zip (an MSI) or the final standalone 1.22.0 installer from the nefarius GitHub project. Windows 11 enforces driver signatures, and both of those are properly signed — you should never need to disable signature enforcement or Secure Boot for BetterJoy, and any guide telling you to do so for a “repacked” driver is a red flag. If BetterJoy starts but throws a ViGEmBus error, the repair sequence is in the vigembusnotfoundexception fix.

Administrator mode: only when you need it

You do not normally need to run BetterJoy as administrator on Windows 11. The official guidance is narrower: elevate only if your keyboard or mouse mappings do not respond. Running it elevated permanently is unnecessary and can complicate how other programs see the virtual controller.

If pairing fails on Windows 11

Work the list in this order before suspecting the OS:

• Remove and re-pair. Delete the controller under Settings → Bluetooth & devices, restart Bluetooth, hold Sync until the lights cycle, and pair fresh.
• Update the Intel Bluetooth driver. Joy-Con lag and flaky connections repeatedly trace back to Intel Bluetooth drivers older than 22.180.0 — see the Joy-Con Bluetooth lag fix.
• Check for double handling. If Steam is open and also reading the pad, you can get double input or an apparently dead controller — the pattern is the same as in our double-input guide on the Platforms & Emulators hub pages.
• Test over USB. A cable connection that works while Bluetooth fails isolates the problem to the wireless stack, not BetterJoy.

FAQ

Is BetterJoy v7.1 officially compatible with Windows 11?

There is no official compatibility statement either way — v7.1 predates any such claim. The practical evidence (current issue reports, working users, a Windows 11-ready driver layer) says it runs; treat “community-verified, not author-certified” as the accurate label.

Do I need a special Windows 11 edition of BetterJoy?

No. There is one v7.1 package for Windows, and it is the same file Windows 10 users install. Any site offering a separate “BetterJoy Windows 11 edition” is repackaging that file — get it from the verified source instead.

BetterJoy worked, then a Windows update broke pairing. What now?

Windows updates occasionally refresh Bluetooth drivers or device pairings. Remove the controller, re-pair, and confirm your Bluetooth driver version before changing anything in BetterJoy — in the reported cases the fault sits in the wireless stack, not the app.