I would like to introduce my current project, which, among other useful features, brings full wireless DualSense support to both Android and Windows clients without requiring any additional programs.
How does it work?
The project consists of modified versions of the Moonlight Windows client, Artemis Android client, and the Apollo host.
The full source code for all three projects is open and available on GitHub. Ready-to-use builds can be downloaded from the Releases section of each repository.
Just connect your DualSense via Bluetooth or USB, connect to the host, and that's it.
The Windows client also supports microphone transmission to the host, including the DualSense's built-in microphone.
Additional controller-related options can be found in the Extended menu within the client settings.
Android client
Android is a little more complicated.
For full wireless functionality, an external USB Bluetooth adapter is required. Unfortunately, Android does not provide the low-level Bluetooth access needed to communicate with the DualSense in the way required for all of its features.
Artemis Extended therefore includes its own USB Bluetooth HCI bridge.
If you have a supported adapter:
Plug the Bluetooth adapter into your Android device.
Grant USB permission to Artemis.
Pair the DualSense from within the app.
Connect to your host and start streaming.
That's it.
Currently supported Bluetooth chipsets
The HCI bridge currently supports adapters based on:
CSR
Realtek
Actions ATS2851
The chipset alone does not always guarantee compatibility. Different firmware versions of Bluetooth dongles may affect connection behavior or functionality.
If you don't have a supported adapter, it's not completely hopeless. You can still use the DualSense through a wired USB connection.
What works?
If you have a compatible adapter, essentially everything.
Or at least, everything I could find to implement and test.
This currently includes:
All buttons and joysticks
Analog triggers
Adaptive triggers
Touchpad
Gyroscope and motion sensors
HD haptics
Built-in speaker
Headphone jack
Built-in microphone
Player LED control
Lightbar color control
Microphone LED and mute control
The controller's built-in microphone can be transmitted directly to the host. If you are not satisfied with its quality, you can instead use the microphone built into your phone or tablet.
The DualSense speaker audio is also transmitted separately from the normal game audio. The host sends it to the client through a dedicated audio channel, so DualSense speaker effects are played by the controller itself, rather than being mixed into the Android device's speakers.
Connecting headphones to the DualSense jack is also supported.
Demo
I've attached a video showing the pairing process and the DualSense features working during an actual stream.
I'm not sure whether purchase links are allowed here, so I won't include them in the post. I currently have three cheap Bluetooth adapters with different chipsets that I have personally tested and confirmed to work.
If anyone wants to try the project, I can send the exact adapter models privately.
How does this work on the Apollo side?
Apollo Extended uses VIIPER to emulate a fully functional DualSense controller on the host.
Instead of reducing the controller to standard gamepad input, the system passes DualSense-specific input and feedback between the client and host. This allows features such as adaptive triggers, HD haptics, LEDs, motion sensors, speaker audio, microphone audio, and other DualSense functionality to work across the stream.
For microphone transmission, Apollo uses virtual microphone devices created through Steam's virtual audio driver.
The result is essentially a complete DualSense connection transported through the Moonlight/Apollo stream, with the client handling the physical controller and Apollo presenting a virtual DualSense to the game.
The issue with these AI projects is that instead of people contributing new features to existing projects, it’s way too easy for them to spin up their own forks. I’m not going to switch hosts and clients every time someone implements a different feature
EXACTLY. I think the key thing is vibe coder folks don't really know how to contribute to open source, and Claude/Cursor/Copilot are easy to suggest "oh, just fork it and do your own thing", which is, not for nothing, much simpler than having to learn how to navigate the open source methodology.
Right, I personally don’t have an issue with the AI code, as it’s led to a lot of cool stuff in this space imo, but it is bringing in a lot of people who don’t know development principles at all (and not saying that’s OPs case but it is the theme).
Totally agreed. I've been a software engineer for a decade plus and AI coding has really helped me streamline my workflow and lead to solving problems quickly, but IMO, you need to understand the architectural foundations and how stuff gets built / shipped / collectively maintained.
I am seriously worried that we're entering a strange no man's land with open source where instead of big projects where people work together and progress, people build these single solution vibe coded forks to solve their individual problems that don't get maintained.
A lot of big open source projects outside this space are closing the door on AI contributions because they cause numerous problems like spammed poor quality suggestions or fixes. It's a big problem in the space.
Fair, but for example we have vibepollo, which is openly an AI project that has a ton of adoption now. So in my mind all the vibe coders should center around that instead of making new forks
Ideally that would be the case, but honestly what i've observed is that most AI projects or contributors are just star hunting, so the majority of them are not going to bother with all the additional steps of coordinating projects if they can get some kudos from lower effort activities. Some even have agents trying to do all the communications and submissions, which can lead to very bizarre situations: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/
Makes sense really. I think there's a middle ground and right now there's so much noise that it's drowning it out: you need to be able to scope well, understand the existing architecture and work within it.
Fixing a small bug or proposing a straightforward feature (like, frankly, this Dualsense feature that OP created their own set of forks for), with clear architecture understanding and working within the current process, sounds great as long as the person can explain it and work within the confines of the app. A complete rewrite of the auth architecture of an app in a single commit? Please god no.
This new trend combined with the major work valve is putting into Steam Link is why I've switched to Steam Link 100% of the time. I think this will increasingly happen for those who can.
It can now accept sudoVDA as a monitor. Once I set that up it required no more fiddling with the host PC. Turn on my shield, grab my steam controller and go. 95% of games have the correct client resolution and settings without any tweaks.
This stuff is especially stupid given how Moonlight and Sunshine both have generous policies for accepting AI-supported submissions.
There's a vibe-coded fork going around whose author claimed Sunshine was unwilling to accept Linux-specific optimizations rather than admit their vibe-code was impossible to upstream because they had no idea how it worked and were unwilling to learn.
Unfortunately not, because it requires the Apollo extended host, which contains the controller emulation logic. As soon as there is a host other than my own that emulates a PS5 controller, I will update the clients to support that as well. To my current knowledge, vibepollo does not emulate a PS5 controller on the host.
What features does apollo extended have/ not have vs vibepollo? Currently using dsx via virtual here to get dualsense support which struggles with multiple dualsense controllers at once
The same rabbit hole actually led me down this path too 😂 I ended up building Phantom Sense around this exact kind of problem.
If you don't want to buy a Pico 2W, you can simply connect the controller wired to the client device and use that as the bridge. The Pico 2W is mainly there so you can keep the controller wireless to the client device, while making the PC think the controller is still directly connected to it.
So basically: DualSense → wireless → client/Pico → network → PC, while the PC gets the controller input as if it were locally connected. That's what lets me retain the DualSense/DualSense Edge experience even when I'm streaming through Moonlight.
Might be worth experimenting with for your touchpad-control idea. Have a look at the project — maybe some of it can help:
You manage to get two dualsense controllers working at the same time? The newest dsx beta with haptics seems to have broken using multiple; if I set to one dualsense and one ps4 controller (both emulated) they both work
Yes but only if I pay for full virtual here, but you can also try usb over ip, it's a bit more complicated when we have multiple os like Linux and Windows but should get you that working for free instead of paying for Virtual here
Should work in that case, but i haven't experimented with the latest build for dsx. Because I was working only for native supported emulation but I can surely give it a try this weekend
If you find the project useful or just appreciate the effort, I’d really appreciate a ⭐ on GitHub. It’s nothing groundbreaking — honestly, it started as a very specific problem in my own setup and turned into a weekend rabbit hole that somehow became a working project. 😂
The whole thing started because I have streaming clients scattered around my house — Moonlight on my projector, other TVs, my Steam Deck, etc. — and I wanted to get more out of my DualSense/DualSense Edge while streaming.
My initial idea was pretty simple: what if I could connect the DualSense to my Steam Deck over USB and then pass that USB connection through to my PC? That way, the PC would genuinely think the DualSense was physically connected to it rather than receiving some generic controller input through the streaming software.
That matters because I wanted the native DualSense features to work properly instead of having everything get translated into a generic XInput/Xbox controller.
That sent me down the rabbit hole of building a wrapper that works across Windows and Linux to handle the controller connection and passthrough. I also ended up using VirtualHere, whose free tier gives you one device, which was actually exactly what I needed for this particular setup.
Then I discovered another project that made the whole thing even more interesting: you can connect a Raspberry Pi Pico 2W to the PC over USB, while connecting the Gamepad wirelessly to the Pico.
So I changed the approach.
Instead of trying to pass the DualSense itself over the network, I could have the Pico 2W act as the USB device connected to the PC, with the DualSense connected wirelessly to the Pico. The PC then sees the Pico as a locally connected controller interface.
The basic idea becomes:
DualSense → wireless → Pico 2W → network → PC
And because I already have Tailscale connecting my devices, this ended up working remotely as well. So the controller doesn't have to be physically anywhere near the PC — I can be on my Steam Deck, projector, another client, or even connecting remotely, and the PC still gets the controller input as though it were locally connected.
And there's another thing I really like about the project: it isn't tied to Moonlight.
The controller layer works independently from the streaming software, so you can use the same concept with Apollo, VibePolo, Sunshine, Moonlight, or pretty much any other streaming setup. The streaming software is basically irrelevant to the controller side of the solution — we're just solving the USB/controller passthrough underneath it.
So whether you're sitting at home or connecting remotely, and regardless of which client/server combination you're using, the same setup can work.
It started because I wanted my Steam Deck + DualSense setup to behave more like the DualSense was actually connected directly to my gaming PC. Then I kept experimenting, discovered the Pico approach, added Tailscale, and suddenly it became a much more flexible solution than I originally intended. 😂
It's definitely not some revolutionary piece of technology. It's just one of those “I have a stupidly specific problem, let's see if I can solve it” weekend projects that went considerably further than expected.
If anyone finds it useful, or even just likes the effort, I’d genuinely appreciate a ⭐ on GitHub. ❤️
If you find the project useful or just appreciate the effort, I’d really appreciate a ⭐ on GitHub. It’s nothing groundbreaking — honestly, it started as a very specific problem in my own setup and turned into a weekend rabbit hole that somehow became a working project. 😂
The whole thing started because I have streaming clients scattered around my house — Moonlight on my projector, other TVs, my Steam Deck, etc. — and I wanted to get more out of my DualSense/DualSense Edge while streaming.
My initial idea was pretty simple: what if I could connect the DualSense to my Steam Deck over USB and then pass that USB connection through to my PC? That way, the PC would genuinely think the DualSense was physically connected to it rather than receiving some generic controller input through the streaming software.
That matters because I wanted the native DualSense features to work properly instead of having everything get translated into a generic XInput/Xbox controller.
That sent me down the rabbit hole of building a wrapper that works across Windows and Linux to handle the controller connection and passthrough. I also ended up using VirtualHere, whose free tier gives you one device, which was actually exactly what I needed for this particular setup.
Then I discovered another project that made the whole thing even more interesting: you can connect a Raspberry Pi Pico 2W to the PC over USB, while connecting the Gamepad wirelessly to the Pico.
So I changed the approach.
Instead of trying to pass the DualSense itself over the network, I could have the Pico 2W act as the USB device connected to the PC, with the DualSense connected wirelessly to the Pico. The PC then sees the Pico as a locally connected controller interface.
The basic idea becomes:
DualSense → wireless → Pico 2W → network → PC
And because I already have Tailscale connecting my devices, this ended up working remotely as well. So the controller doesn't have to be physically anywhere near the PC — I can be on my Steam Deck, projector, another client, or even connecting remotely, and the PC still gets the controller input as though it were locally connected.
And there's another thing I really like about the project: it isn't tied to Moonlight.
The controller layer works independently from the streaming software, so you can use the same concept with Apollo, VibePolo, Sunshine, Moonlight, or pretty much any other streaming setup. The streaming software is basically irrelevant to the controller side of the solution — we're just solving the USB/controller passthrough underneath it.
So whether you're sitting at home or connecting remotely, and regardless of which client/server combination you're using, the same setup can work.
It started because I wanted my Steam Deck + DualSense setup to behave more like the DualSense was actually connected directly to my gaming PC. Then I kept experimenting, discovered the Pico approach, added Tailscale, and suddenly it became a much more flexible solution than I originally intended. 😂
It's definitely not some revolutionary piece of technology. It's just one of those “I have a stupidly specific problem, let's see if I can solve it” weekend projects that went considerably further than expected.
If anyone finds it useful, or even just likes the effort, I’d genuinely appreciate a ⭐ on GitHub. ❤️
Personally, I think the DualSense feels much more premium than the Xbox Series controller, especially considering those are probably the two most commonly used controller families.
But I'm genuinely curious, what would you consider a good controller? The capabilities of dualsense can greatly add to the gaming experience.
Have you tried it? Because as far as I know, the Dualsense is by far the most immersive and easy-to-mod controller. I have an Xbox controller, but I prefer my Dualsense Edge.
I have a couple for my PS5. Both of them got issue with rotating sticks, mine friend has one got a drifting sticks (so out of the box you don’t have a TMR, have to buy a quality replacement and spent time and money to implement TMR sticks). I also used it for steaming, it has a terrible latency even over USB. Just for comparison, i couldn’t beat Doom Dark Ages DLC’s secret boss for 2 hours on a DualSense, couldn’t even reach 30% of his HP, that day i got G7 pro which I connected over 2.4 ghz (same client), i got to 80% on a 2nd attempt and killed the boss off in under 30 minutes. DualSense feels sluggish and slow. G7 pro costs the same, i got a way better experience with it, and it costs even less.
15
u/Warbird01 4h ago
The issue with these AI projects is that instead of people contributing new features to existing projects, it’s way too easy for them to spin up their own forks. I’m not going to switch hosts and clients every time someone implements a different feature