Does this happen right at the start of a game, or the first time the game should rumble the controller? In the latter case, there may be an issue with the Bluetooth protocol: While developing the xpadneo driver, we found that the controller doesn't like rumble data to be sent faster than 10ms intervals per frame - otherwise the controller seems to crash/desync internally and doesn't stop the rumble motors.

It starts somewhere between pressing the "play game" button and the actual game starting, somewhere in that second or two. I wasn't using xpadneo, I had used the xow and xone drivers, (never both at the same time). I tried one, then the other, then uninstalling both just to see what would happen and in every case, the same controller worked fine on the actual PC, but vibrated uncontrollably when used via steam link.

Okay, then it's not that protocol thing but something different. I just wanted to differentiate between those two.

been having steamlink linux bluetooth xbox controller issues for a while now.
another thread about it https://steamcommunity.com/app/353380/discussions/0/3124912256628622960/

We lately had this discussion on the xpadneo Discord server: It was solved after revoking user session access to the hidraw device, so there's probably something broken in SDL and its hidapi driver.

I am also experiencing this issue. Xbox controller will vibrate constantly once a game is launched when the controller is connected via bluetooth. The controller will continue to vibrate until it is manually turned off.

EDIT

Apparently OpenRGB udev rules was the culprit. Removed OpenRGB udev rules fixed the vibration issue.

This is 100% reproducible on the Steam Deck with an Xbox Series X controller.

Pick a game that has a ton of rumble (e.g. Dirt Rally 2.0) and it vibrates like crazy. It's as if there is some sort of queue of vibration events that can never be interrupted and once the game sends them, they will execute for a looooooong time. Even exiting the game doesn't cease the rumble.

It happens when playing directly on the Steam Deck as well as when streaming from my Windows PC to the Deck.

With BLE firmware 5.x of the Xbox controllers, rumble programming needs to be throttled to 20hz (intervals of 50ms, the previous firmware supported 100hz, intervals of 10ms). Steam Input uses SDL, as far as I know, and SDL does not have this fix. You can use the xpadneo driver and disable Steam Input to work around this problem, except that installing xpadneo on the Steam Deck may be a bit difficult. Even the plain HID drivers of the kernel do not properly support this, as they do rumble at 50hz (20ms intervals).

With BLE firmware 5.x of the Xbox controllers, rumble programming needs to be throttled to 20hz (intervals of 50ms, the previous firmware supported 100hz, intervals of 10ms). Steam Input uses SDL, as far as I know, and SDL does not have this fix. You can use the xpadneo driver and disable Steam Input to work around this problem, except that installing xpadneo on the Steam Deck may be a bit difficult. Even the plain HID drivers of the kernel do not properly support this, as they do rumble at 50hz (20ms intervals).

@kakra according to this article, the kernel driver should support it properly now.

But yeah, using xpadneo isn't a real solution for the Deck. Some work is needed somewhere else for that.

@kakra according to this article, the kernel driver should support it properly now.

This is only for supporting rumble at all. The problem is in the ff-memless driver. But I was a little wrong, it actually uses 20hz intervals for envelope updates:
https://github.com/torvalds/linux/blob/4da34b7d175dc99b8befebd69e96546c960d526c/drivers/input/ff-memless.c#L28

The real problem is something else: It can calculate the start of new envelopes for intervals lower than what the Xbox controller firmware supports, and that's crashing the rumble loop in the controller leading to endless or queued rumble.

What ff-memless needs, is another effect state for calculating a timeout to not send new rumble commands before. I'm working on such a patch in an effort of upstreaming parts of features from xpadneo to the kernel. But that may take some time because some stuff still needs to settle. Currently, such a rumble throttler is in xpadneo, xone, xow. The kernel doesn't really have one as it's only an envelope update interval. And SDL still throttles to 100hz (when I looked last).

The other thing is that Steam Input and SDL simply bypass such driver knowledge by using hidraw directly (for many devices, not for all). So they need to implement their own knowledge of such limitations. Thus, preventing hidraw access for the Steam Deck Client could also work around your problem but then again, the mappings may be messed up because the HID descriptor of the Xbox controllers is just silly, and the kernel drivers don't care, plus ff-memless isn't really throttling rumble commands.

This is 100% reproducible on the Steam Deck with an Xbox Series X controller.

Pick a game that has a ton of rumble (e.g. Dirt Rally 2.0) and it vibrates like crazy. It's as if there is some sort of queue of vibration events that can never be interrupted and once the game sends them, they will execute for a looooooong time. Even exiting the game doesn't cease the rumble.

It happens when playing directly on the Steam Deck as well as when streaming from my Windows PC to the Deck.

I know this is an old thread, but wanted to add some information.

I have the exact same issue you describe:

Just started to play dirt rally 2 on my Apple TV with steam link to my windows pc, and it shows the same issue. It keeps rumbling after quitting the game for a while - like some sort of queue needed to be flushed.

Since I have the same but on appletv with steam link app, I'm not sure if this issue is in the right repo?
(Idk if its the same issue for Linux though)

@kisak-valve FTR, if Xbox Elite 2 controllers are involved, these controllers need acknowledged GATT writes to send rumble, otherwise rumble reports may queue up or get lost, eventually resulting in the firmware crashing. Previously, we prevented that in xpadneo by sending rumble at only 20 Hz.

• https://github.com/atar-axis/xpadneo/commit/01c059eb558c9e468cf292b52341197a8804d81b (switch to GATT Write Request)
• https://github.com/atar-axis/xpadneo/commit/153b6b6a5078df6e2aa2c75c552f229e9ac9f3ef (remove old throttling, use fallback of 50 Hz for non-HOGP write path)

If SDL uses the hidraw write path, it should implement a similar solution because the kernel will not be involved in any throttling.

Actually, all modern BLE controllers should probably switch to this new method - but the Xbox Elite 2 controllers are most heavily affected by this.

If using kernel drivers like hid-microsoft, this GATT Write Path is not implemented there and still needs aggressive throttling to not overwhelm the firmware and desync it.

Limiting games to 60 fps rendering can mitigate this issue because games usually only send one rumble update per rendered frame. But if ff-memless becomes involved (which we removed lately from xpadneo), frequency aliasing effects may result in shorter rumble update cycle bursts which crash or dysync the firmware.

@slouken is already tagged here, so SDL devs should get knowledge of these new findings. It has been discovered by GloriousEggroll.