Could someone explain what this is for? I have an XSX wireless controller. I use it over BT with my Linux machines and it works out of the box with all games and the desktop. What functionality does this add?
this post was submitted on 21 May 2025
135 points (99.3% liked)
Linux Gaming
18622 readers
562 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
Resources
WWW:
Discord:
IRC:
Matrix:
Telegram:
founded 2 years ago
MODERATORS
A fork/continuation of the original since the author has been away for a while. Supports kernels up to 6.15 with lots of other changes.
top 38 comments
sorted by:
hot
top
controversial
new
old
If you use the wireless adapter this is required. I mainly use Linux but sometimes boot into Windows. Hence it’s easier to use the adapter and have it paired with the singular thing, than to re-pair it with Linux/Windows each switch.
It's for the official wireless dongle. It has lower latency and longer range than bluetooth, and you can move the dongle between PCs without having to re-pair the controller.
I was getting terrible and inconsistent input lag with an XSX controller. Something about it not correctly reporting its polling rate over BT. Switching to the dongle fixed it.
Glad yours works, but not everyone is so lucky.
I use it because the default driver would not work with my Thrustmaster controller that uses the Xbox controller standard.
I wish steam deck os would get this. I installed it a few times but it gets overwritten with updates.
I have a few old style xbox one controllers (without bluetooth) and need a xb wireless dongle to use them. It works fine with this driver.
Interesting, I wonder if this is more stable than it is on Windows?
I find it handles controllers just fine, but I find the headset (the official Xbox one) drops out regularly. Still leaps and bounds better than Windows Bluetooth, but the drops definitely worsen the experience. Although it also did that to me on Series X.
...
The fact that this made a patch message of any kind, MUCH less the announcement...
It should be in Bluetooth or HID, broken hardware that doesn't follow standards is nothing to be proud of.
Well people who own the official Xbox One wireless adapter will have to disagree since that requires firmware with an incompatible licence and won't get into the kernel. If you want to not use the poor Bluetooth on Xbone controllers or have an older controller that does not have Bluetooth you'll have to use this. Plus this release gives publicity to the project which the previous owner neglected since he went MIA twice.
It's trash hardware.
Xbone owners should be shaming ms into oblivion for making the kernel have to pollute itself with this garbage.
Note how ps5 controllers need 'power' (optional).
The wireless adapter functions extremely well and is no different than any Wi-Fi 2.4GHz dongle, in essence.
This driver also works really well.
I fail to see how two things working well together somehow results in your rant.
Because I've worked on hardware, and have drivers in the kernel.
It's trash hardware if you're duplicating the functionality of something else and not following the standards.
https://www.techspot.com/news/105268-linus-torvalds-fed-up-making-kernel-changes-address.html
Microsoft could do a firmware update to fix their worthless broken shit, Bluetooth is like 20 years old now, you'd think even a company with their heads that far up their asses could get it right by now. For the dongle, have it present hid.
They're just adding more trash drivers to the kernel we shouldnt need.to throw shit code for their shit drivers into the kernel repo everyone uses.
Alright what drivers have you worked on?
A bunch, mostly networking but some sriov and arm64 and old mips64 stuff.
Enough to have been on the bad side of one of linus's rants.
This is shit engineering and msft should be shamed for it.
This isn't a Bluetooth adapter.
That's how little you know about the subject you're trying to rant about.
What in the fuck are you even talking about?
PS5 is bluetooth, standard bluetooth, and wired uses both standard HID and standard usb audio, my point is: Why isn't MSFT?
Also, since you clearly don't know the first fucking thing you're talking about:
After 2016, when Bluetooth connectivity was introduced with the second controller revision (model 1708) alongside the Xbox One S, Microsoft rebranded its proprietary connection protocol as "Xbox Wireless".[10] Xbox Wireless uses the same frequency range as Bluetooth (2.40-2.48 GHz), but has a higher transmit power, improving range and input latency. Starting in 2017, Microsoft began working with third-party manufacturers to produce additional accessories using Xbox Wireless, with the first class being headsets.[11]
With a firmware update that began rolling out in September 2021, controllers with Bluetooth are able to pair with devices using both wireless protocols, allowing those controllers to switch connections by double-tapping the pairing button.[12]
Drivers were released in June 2014 to allow Xbox One controllers to be used over a USB connection on PCs running Windows 7 or later.[69] The Xbox One Wireless Adapter for Windows is a USB dongle that allows up to eight controllers to be used at once wirelessly.[70]
Look at how stupid broken this is! You need drivers to use it over standard USB!
Everything about this design is broken, it should be kicked out of the kernel and MSFT should release firmware that actually implements HID like normal, non-stupid people.
8bitdo has exactly this, same dongle system and pairing and again, it works perfectly without any drivers at all, because they're not morons.
We are talking about a driver for the Xbox One wireless adapter.
Microsoft never submitted a kernel driver for this, it's a third party module. It's not Bluetooth - it's WiFi, using a proprietary blob for authentication.
Not a single one of your claims in this entire thread have been correct.
It’s not Bluetooth - it’s WiFi, using a proprietary blob for authentication.
You've literally missed my whole point.
Playstation link is this exact same thing, and btw, both controllers are dual-mode bluetooth and "high-speed wireless interface", which is basically wifi or wifi-direct or some proprietary variant.
My point is, why isn't it like Playstation link which just presents as HID devices and usb-audio devices, without a driver at all? Same low-latency, they even do LDAC.
The 8bitdo version is easier to implement because it's one dongle per controller. The Xbox dongle supports eight controllers per dongle. This complicates things; I assume they didn't want to emulate an eight-port USB hub on the dongle.
You can use BT, but there's a reason 8bitdo has a dongle as well: BT has worse latency, I assume due to protocol overhead.
And at least Xbox controllers are cross-compatible. You can't use a DS4 on a PS5, even if you're playing a PS4 game.
assume they didn’t want to emulate an eight-port USB hub on the dongle.
https://github.com/abcminiuser/lufa
Literally a kid did this in high school, this is without hardware support, just GPIO, but he also implemented the full stack on avrusbs and cortex-ms, and one thing he emulated was multiple devices on a hub.
Well, yeah, obviously it can be done. What's the latency, though? A hub's muxing alternates between packets from different devices, but even USB 1.1 has 64B packets, leaving 64b per controller if you report them all in one packet. That's 15 digital buttons, 6b per axis, and 13b left over for routing.
However, I can't think of a way to get the computer to decode one 64B packet into eight separate HID polls without a custom driver. If you use a hub, you're limited to 8kHz total by the spec, but many EHCI controllers limit that to 1kHz. 125Hz per player is not great.
I can't confirm that this is the reason or that there isn't a different way around the restriction, but it seems likely from what I know of USB hubs.
TL;DR: with a custom driver, you can report all controllers on all USB polls rather than each taking up a whole interval, giving you 8x the polling rate compared to an emulated hub with 8 standard HIDs.
Firstly, it's not a real hub, it's an emulated hub, and you can do that emulating everything as USB 2.0.
Secondly you can have multiple hid interface endpoints on a single device.
Thirdly, you wouldn't be polling, these would be hid interrupt urbs, and you can storm them 1 per micropacket if you want, they just show up in the ehci buffers.
Finally, no human is overflowing the hid interface like this, not even 8 of them.
- You'd presumably do it as 2.0, but I used 1.1 for the numbers just to demonstrate that you can definitely fit 8 controllers into a packet even if you go for unreasonable levels of backwards compatibility.
- Without a hub, I'm not aware of a way to exceed 8 axes per HID device (7 in Windows for some reason). Each Xbox controller has six, so even two controllers can't be one device.
- As far as I can find, most USB 2 implementations can take up to 1000 packets per second per root hub, regardless of packet size. I was already assuming one controller poll per packet for the hub version, and that's 125Hz per controller with all eight.
- You aren't actually pressing buttons at 125Hz, no. However, if your input is barely too late for one 125Hz poll, you can get enough delay to be noticeable in fast-paced games. Most controllers and mice use 1kHz for this reason, with some even supporting up to 8kHz if your USB implementation supports it (which apparently is pretty common with xHCI, but Microsoft didn't want to rely on that for obvious reasons).
if your input is barely too late for one 125Hz poll,
So those polls are generally isochronous to the USB bus transaction state, not based on polling frequency of the CPU, what happens is:
-
USB interrupt URB comes in to HCI controller,.URB descriptor written to descriptor chain.
-
Controller adds to descriptor chain, once chain length > WAT (| Timeout), interrupt and start processing incoming URBs.
-
In interrupt controller, follow chain, push URBs onto usb stack queue, trigger handler tasklet
-
Stack processes URB, routes to proper class driver
-
Class driver checks if URB has file handle open (or has open ref from drivers like HID/input).
-
If so, poll or other input read() returns value.
Now it's possible there are multi-input poll reads in games, and I'm doing linux of course.
For MSFT it's URB -> IRP -> WDM filter driver stack -> kernel32/directinput or win32 input stack (WNDPROCs after routing).
In any of these cases, I'm struggling to see how interrupts would come in faster with the same code on PC.
See, the same code probably runs on both MSFT and normal hardware, so it's going to have the same structure, unless you actually believe a dev team is optimizing input latency that much, that's often the lowest priority, they'll optimize video lag more because it's more noticeable. The engines themselves use DirectInput, and that's routed through to libinput in WINE, and the same for all devices.
Btw, DirectInput has a device-based interface, so it couldn't poll like this anyway, basically each controller has its own input queue that is round-robin and pluck stuff out of their input stream when available.
In any case, you're not getting the latency improvement, both because it's so different in software and because nothing can appreciate this.
I'm not trying to be extra autistic for no reason, I've just had to make these decisions before, and these are how we have to think.
Microsoft could do a firmware update to fix their worthless broken shit, Bluetooth is like 20 years old now, you’d think even a company with their heads that far up their asses could get it right by now. For the dongle, have it present hid.
No one has done bluetooth right because you can't do bluetooth right here.
My ps5 by works perfectly, as did my ps4 pad.
Think the ps3 one was USB, but that's fine too.
Even the audio works out of the box.
I use my 8bitdo which is great too.
Everyone else can do this correctly, and when someone can't they should be shamed, like msft.
nether ps4 nor ps5 have working audio over bluetooth, and they also have high latency. PS5 controllers also don't support the enhanced rumble since it also uses audio. I don't use 8bitdo any more due to constant the enshitification of their hardware, but I doubt they support low latency with audio either.
You seem to be having a lot of problems here:
https://direct.playstation.com/en-us/buy-accessories/playstation-link-usb-adapter
Low latency, lossless audio, pretty sure rumble works.
And NO DRIVER outside of the standard USB hid and audio.
How is this hard to understand?
this is not bluetooth.
Neither is the xbone dongle, as you argued.
The difference is: The dongle uses all the normal standards, and doesn't need a kernel driver like the msft piece of shit.
no, I said;
No one has done bluetooth right because you can’t do bluetooth right here.
so you have me mistaken with someone else. Also, im not sure I appreciate why does it matter if a driver is in /hid or /input/joystick in this regard?
If you need a dedicated driver anyways, what is the difference between them?
My point is that the PS link doesn't need a dedicated driver, why does this one?
yeah, but pslink does still require hid/playstation. this is an newer replacement to joystick/xpad with more features. IMO that is more or less roughly the same there.
Hid is what should be required.
There are a million standards already here, I'd they really want to they can extend hid or something.
This is just a scrappy proprietary driver for no reason :(
or maybe it is sexual preference? holding playstation controller feels little like holding turds. dont like em at all.
I can respect that, I just think there should be a lot of pressure on MSFT to reprogram firmware to support linux natively.
The kernel has been desperately trying to move away from these 1-off, quirky drivers as they're impossible to maintain.