Show HN: Linux driver for the Xbox One wireless dongle(github.com)
github.com
Show HN: Linux driver for the Xbox One wireless dongle
https://github.com/medusalix/xow
22 comments
Thanks for working on it, I'll see if I can get it packaged to Debian during the holidays.
Finally! :) I have one with borked USB port (I think the 1537 one), if it works this may make it useful again.
Thanks for working on this!
Thanks for working on this!
Curious how you charge if if the usb is "borked"
At least the original xbox one controller used AA batteries by default, and had an optional accessory rechargeable battery pack to replace the AA batteries. Maybe the later models are different; I don't have an xbox anymore.
Replacing the AA-bateries?
At least my xbox one controller has a slot for two aa bateries on the back.
At least my xbox one controller has a slot for two aa bateries on the back.
Interesting. My controller that I got only a few months after xbox one launch has a proprietary rechargeable battery in that slot
Nice project!
Initial thought: apart from ease of development, is there any reason to do it in user space?
I looked into uinput before to get a Bluetooth mfi controller working, but couldn't figure out which modules of the kernel did what.
Ease of development is underestimation.
I’ve built a few user space Linux drivers for SPI and USB devices. Was easy, I have consumed stable APIs exposed by usbdevfs, libudev, and a few others. No need to recompile OS kernel. Because Linux kernel API is stable, not only OS kernel upgrades don’t break my stuff, they don’t even require me to recompile my code.
Creating a kernel mode Linux driver is much harder in comparison.
Merging a driver into the mainline Linux is borderline impossible. Even Google with all their corporate resources and platinum membership of Linux foundation was unable to do so, instead they are supporting many thousands lines of patches: https://source.android.com/devices/architecture/kernel/andro...
It’s safe to assume you won’t be able to push your custom driver either. You’ll have to do it the same way as everyone else — patch locally. This is not trivial either, but this time the challenge is technical, not political, as Linux kernel doesn’t have stable API nor ABI: https://github.com/torvalds/linux/blob/master/Documentation/...
I’ve built a few user space Linux drivers for SPI and USB devices. Was easy, I have consumed stable APIs exposed by usbdevfs, libudev, and a few others. No need to recompile OS kernel. Because Linux kernel API is stable, not only OS kernel upgrades don’t break my stuff, they don’t even require me to recompile my code.
Creating a kernel mode Linux driver is much harder in comparison.
Merging a driver into the mainline Linux is borderline impossible. Even Google with all their corporate resources and platinum membership of Linux foundation was unable to do so, instead they are supporting many thousands lines of patches: https://source.android.com/devices/architecture/kernel/andro...
It’s safe to assume you won’t be able to push your custom driver either. You’ll have to do it the same way as everyone else — patch locally. This is not trivial either, but this time the challenge is technical, not political, as Linux kernel doesn’t have stable API nor ABI: https://github.com/torvalds/linux/blob/master/Documentation/...
It's quite the opposite actually, a large company usually expected others to bend to its will and is not that interested in hearing opposed views and change their approach and that's what makes getting coffee into the kernel harder.
I've got code in the kernel and it wasn't easy but that code lives on well beyond my contribution so it has to be in a design and implementation that can and will be maintained by others.
I've got code in the kernel and it wasn't easy but that code lives on well beyond my contribution so it has to be in a design and implementation that can and will be maintained by others.
Until performance is an obstacle, writing drivers in user space first is all benefit. Quick prototyping, crashes don't bring down the system, choice of programming language, etc, etc.
It's this is the major factor limiting driver development on Linux, so it hardly needs another reason. But security is another thing that userspace implementation can do better on, no idea about this case specifically.
Not OP, but there is a history of writing game controller drivers for linux:
https://github.com/chrippa/ds4drv
https://xboxdrv.gitlab.io/
https://github.com/kozec/sc-controller
I recently bought myself a dualshock4 for use with Kodi and RetroArch. No driver was needed, even for bluetooth!
Edit: formatting
https://github.com/chrippa/ds4drv
https://xboxdrv.gitlab.io/
https://github.com/kozec/sc-controller
I recently bought myself a dualshock4 for use with Kodi and RetroArch. No driver was needed, even for bluetooth!
Edit: formatting
One of the major points for me was how cumbersome the installation process for kernel modules is. Now I can just do make install which works on most Linux distributions.
Eeh, I never do a make install from the projects I download TBH, as the resulting files aren't tracked by the package manager.
A kernel module is just a matter of compiling and running `insmod` (or placing it in the correct path). You have to recompile it each time you upgrade your kernel, though.
But seriously, the proper way to do it is a kernel module which you then mainline. I wouldn't be surprised if Valve was to pick it up, since they mainlined some xpad improvements (and the wired version of those controllers)
A kernel module is just a matter of compiling and running `insmod` (or placing it in the correct path). You have to recompile it each time you upgrade your kernel, though.
But seriously, the proper way to do it is a kernel module which you then mainline. I wouldn't be surprised if Valve was to pick it up, since they mainlined some xpad improvements (and the wired version of those controllers)
DKMS is the only way to do it without losing sanity.
Tell that to a friend that runs secure boot enabled.
You can add a step to DKMS build scripts for signing the modules.
> Most of the reverse engineering was done by capturing the communication between the dongle and a Windows PC using Wireshark
Haha that's pretty cool
Haha that's pretty cool
If Windows is the only platform (apart from the Xbox) where the dongle works, there's also not much of an option if you want to intercept valid traffic relatively easily.
Thank you so much! I was just to buy the Bluetooth ones but it seems like I don't have to.