Rumble problem - Xbox Series S controller #311
Comments
|
With the XBXS controller, this is most likely a Bluetooth issue we cannot work around in xpadneo directly as it is not a Bluetooth but a HID driver. I tested the latest commit for multiple months now with all three models (XB1S, XBE2, and XBXS) and hand no issues, rumble was more consistent across all games. But there's an issue with bluez that may use wrong latency settings. From your description, I read you already tried those (it's documented in the troubleshoot docs how to set those). Be sure to reboot after you applied the settings, maybe purge the bluez devices cache and remove the device, then pair it again, just to be sure. But FWIW, could you try the previous commit? It should change nothing about the behavior except that you see more consistent rumble strengths during the game reprogramming the strength a lot of times. If the game sets rumble=0, this will pass through to the controller, as we have a special case handling for this. So everything should be fine. What you describe (5-10 seconds, maybe even 20s sometimes) is usually a Bluetooth issue I observed, too. According to MS, you should stop using other Bluetooth devices nearby, or on the same Bluetooth adapter. Also, there's the latency issue. You should also upgrade to the latest XBXS firmware using a Windows system (rumor says there has been an update lately, I didn't try it yet). If you changed any settings (latency, firmware version), it usually requires to remove the controller from Bluetooth, purge the Bluetooth cache, then pair it again. The internal controller details seem to be a little quirky. You may even need to pair it to a different computer once to clear its internal state. There may be a third problem: Steam may use the gamepad in hidraw mode which doesn't work quite so well due to the quirks of the XBXS controller. Try disabling Steam Input for the game or in the global Steam settings. Also check Try stopping/uninstalling kdeconnectd if you have that. There's a lot of Bluetooth related information here: https://github.com/atar-axis/xpadneo/projects/11
Please don't, I could read everything perfectly. ;-) |
|
Thanks for quick reply!
I used previous commit before - same behaviour. I thought last commit can help me (throttling fix) - no result, so I have to make new issue.
Yes, I updated my gamepad via Windows (now XBXS hasn't any updates). Latency changed before. Tried to do this again - nothing changed. Tried to connect to another device (Android). After that couldnt connect to PC. Connect to Windows via VirtualBox helped me. Now XBXS connect to PC (Linux) without troubles.
Tried that too - nothing changed.
I dont have kdeconnectd. I use GNOME with GSConnect. But it uses wifi. P.S. I run games not via Steam - directly via wine (just use Proton version) |
|
GSconnect may exhibit the same behavior as kdeconnectd because they largely are designed from the same code base. kdeconnectd has a bug where it spams (or something triggers it to spam) the Bluetooth radio with scanning requests (no matter how and if your phone is connected) every 10-20s which puts the receiver into discovery mode and lasts for 20s. XBXS and discovery mode do not play nice together. GSconnect may do something similar. Try stopping it and see if the problems are gone. It was covered here: bluez/bluez#123 If you can make the same observations with GSconnect running, you should report that upstream to GSconnect. |
|
I disabled GSConnect (turn off extension), delete bluetooth connection, clear cache, reboot - connect (with 3 time), make chmod (just in case), start game - same behaviour |
|
Tried to disable WiFi - in my feel rumble duration was decreased, but still it's. |
|
This may feel like it's becoming dumb or silly... But after all, MS suggest that there may be air-time concurrency issues with the controller. If disabling wifi helps the issue, then this sounds like exactly such a problem. Some ideas:
Also it may be helpful for diagnostic if you'd look at the output of While BTW: Different models work differently when looking at them in |
|
Yes, I have combined BT/WiFi adapter (laptop). Here some output from From output I made conclusion: 45 packages of data was send/recived from XBXS at 1,12263 sec. Data continued enter to log when I released button. Is it normal or not I dont know. |
|
No that's not how it should work: XBXS should stop sending data immediately (or maybe after 10-15ms). So I suppose your combined adapter may have driver problems because it doesn't communicate back to the gamepad properly. This is handled completely in the Bluetooth stack of the kernel and the bluez daemon, long before xpadneo sees the data. So here's some ideas to try:
|
|
BTW: The controller has an internal rate of 100 Hz for the protocol, so it should send packets at 100 Hz, that is at 10 ms intervals. Your log shows intervals between 20-40 ms, and I assume that's why protocol data queues up and you're seeing delays and latency. You could try changing the source code to throttle the rumbler to 50ms intervals to slow down how much data xpadneo sends TO the controller but you will still see input latency of around 30ms at least which is already quite noticeable during gaming. Usually, we receive input data after 10ms in the worst case with a proper BT dongle. Not counting internal delays in the controller, this will add another 16.6ms frame latency at 60fps, so you're already near 50ms latency which is already very noticeable. |
I took new TB4.0: Some In the end: nothing changed (even by fully disabling combined BT+WiFi) upd: added upd2: Kernel: 5.13.12-200.fc34.x86_64 Bluez: 5.61 |
|
Okay, now things are getting strange... The btmon tells me the device is paired to hci0 which is the CSR dongle - so it should work. But you are still seeing the exact same problems? |
|
Today I did some gamaped test: connect XBXS via new BT dongle and test behaviour rumble in GTAV via Wine and GTAV via Moonlight (stream from Windows). Via Moonlight gamepad rumble works perfects! But via Wine - promblems above. |
|
In both cases the gamepad is attached to the Linux host, right? And when you say "wine" - is it upstream wine, or Proton wine? Because those two versions differ a lot in how they use SDL and gamepads. |
Yes
Proton-6.14-GE-2 And I found that rumble strength via Linux more heavy as Windows (real windows machine) Tomorrow will test default wine and give results |
There are multiple possible causes for this:
Could you retry with Proton Experimental? That's the only version I'm testing against because it contains everything that is scheduled for being mainlined to Proton. |
|
So, this my unhurried results: I tried:
Tried |
|
Is this on Fedora Core? I cannot reproduce such behavior here with Gentoo. And your hidraw test shows that it generally works as it should. So the only explanation left is: in games rumble is sent too fast, overwhelming the controller. In dmesg this is logged as a rumble throttle entry. If you don't see that, the games are bypassing the xpadneo driver and we cannot do anything except trying to force the games into not bypassing our driver. |
By default I dont see this message in
How can I force the game uses ps: some info from |
|
Exact same issue here. I've tried several games, and non of them are printing log into dmesg while gaming. However, after I uninstalled xpadneo and reboot, I could connect my controller via bluetooth, but the key mappings in the game are completely messed up. So I guess the games were actually using xpadneo when it's installed, and they are not bypassing xpadneo. And thus I think the rumble issue might be an issue of xpadneo itself, and it never print log for some reason (except for the welcome message) |
|
Well, we can still control what the games see over hidraw: The hidraw reports are patched by xpadneo to show a correct mapping of an emulated original Xbox controller. But we cannot control what SDL2 sends over hidraw. Thus, you'll never see the rumble throttle message if games go via the hidraw device. SDL2 should have a working rumble throttle meanwhile but I'd need to check the source code to confirm this. Looking at the original description (rumble continues for some time when it's supposed to stop), this still looks like some awkward Bluetooth latency problem to me. The XBXS controller may be especially sensitive here. And this may not be solved by rumble throttling. Do you see any input latency? Please look at #198 (comment) for LE latency parameters to set in your bluez configuration and report back. |
|
Thank you so much for such detailed explanation Kakra. I've tried the LE config, but unfortunately, the issue persists. Here's my And And I've recorded some log from
Sorry for such a long reply and my bad English. I really don't understand the btmon log, so I really appreciate if you could help me out with this issue. Thank you good sir! |
Also fixes Steam Input which apparently also uses SDL2. The bug shows up when SDL identifies the controller as being on USB instead of Bluetooth (SDL Gamepad ID starts with `03` instead of `05`) which then messes with SDL's expectations for the contents of hidraw. This fixes two SDL problems: * Wrong mappings in hidraw (buttons shifted to other buttons) * SDL2 doesn't properly throttle rumble commands (endless rumble) See-also: atar-axis#286 Maybe-fixes: atar-axis#303 Maybe-fixes: atar-axis#311 Maybe-fixes: atar-axis#314 Signed-off-by: Kai Krakow <kai@kaishome.de>
Also fixes Steam Input which apparently also uses SDL2. The bug shows up when SDL identifies the controller as being on USB instead of Bluetooth (SDL Gamepad ID starts with `03` instead of `05`) which then messes with SDL's expectations for the contents of hidraw. This fixes two SDL problems: * Wrong mappings in hidraw (buttons shifted to other buttons) * SDL2 doesn't properly throttle rumble commands (endless rumble) See-also: #286 Maybe-fixes: #303 Maybe-fixes: #311 Maybe-fixes: #314 Signed-off-by: Kai Krakow <kai@kaishome.de>
|
After update trouble didn't gone. But rumble behaviour changes: after start game the rumble works. But if I drive via grass the rumble works about 1-3 sec and stops at all (at that time Some |
At least this line tells us that rumble no works through the driver, so we are safe on that side.
This looks like the kernel timing may be off a little bit: The duration is too short, it's designed to run 997ms, and usually I'm seeing values between 995 and 998, your's falls quite out of this range. I'm not sure if you can figure out how to adjust the source code on your own and trying to install it from there... But in the file The workqueue timer is quite coarse in the kernel but usually it should not "undershoot". Could you tell me the output of BTW: The issue shouldn't have been auto-closed. |
Tried change Maybe I reinstalled it wrong? (
My
|
This line won't change by editing the file: The initial rumbler uses fixed rumble lengths. But you may see a different result during the game.
Okay, your kernel has no config.gz support. You could try running |
Also fixes Steam Input which apparently also uses SDL2. The bug shows up when SDL identifies the controller as being on USB instead of Bluetooth (SDL Gamepad ID starts with `03` instead of `05`) which then messes with SDL's expectations for the contents of hidraw. This fixes two SDL problems: * Wrong mappings in hidraw (buttons shifted to other buttons) * SDL2 doesn't properly throttle rumble commands (endless rumble) See-also: atar-axis#286 Maybe-fixes: atar-axis#303 Maybe-fixes: atar-axis#311 Maybe-fixes: atar-axis#314 Signed-off-by: Kai Krakow <kai@kaishome.de>
I didn't try this yet, but I noticed this: if
Today will try to check last commit and various |
This is strange, didn't happen when I experimented with it. Did you keep the |
|
Today tried all values (10-15) of
Of course, I kept |
|
Okay, so we are on a false track here: If 15ms changes nothing at all, there's no timing issue. If rumble stops, do inputs still work normally? |
Yes, input still works as usual |
Firmware 5.13 and later (all BLE models) queue rumble effects if we send rumble commands faster than 20 Hz. This commit fixes it and actually matches the rate the ff-memless emulation is supposed to send us for single effects. ff-memless may still combine several effects and send them at higher update rates thus we need to limit it here. Fixes: atar-axis#337 Fixes: atar-axis#311 Maybe-affects: atar-axis#347 Maybe-fixes: atar-axis#319 Maybe-fixes: atar-axis#180 Signed-off-by: Kai Krakow <kai@kaishome.de>
Also fixes Steam Input which apparently also uses SDL2. The bug shows up when SDL identifies the controller as being on USB instead of Bluetooth (SDL Gamepad ID starts with `03` instead of `05`) which then messes with SDL's expectations for the contents of hidraw. This fixes two SDL problems: * Wrong mappings in hidraw (buttons shifted to other buttons) * SDL2 doesn't properly throttle rumble commands (endless rumble) See-also: #286 Maybe-fixes: #303 Maybe-fixes: #311 Maybe-fixes: #314 Signed-off-by: Kai Krakow <kai@kaishome.de>
Firmware 5.13 and later (all BLE models) queue rumble effects if we send rumble commands faster than 20 Hz. This commit fixes it and actually matches the rate the ff-memless emulation is supposed to send us for single effects. ff-memless may still combine several effects and send them at higher update rates thus we need to limit it here. Fixes: #337 Fixes: #311 Maybe-affects: #347 Maybe-fixes: #319 Maybe-fixes: #180 Signed-off-by: Kai Krakow <kai@kaishome.de>
Version of xpadneo
With last commit 67585b3
Controller Model
Connection mode
Installed Software
Severity / Impact
Describe the Bug
When I play in GTA V via Wine (Proton GE) and ride the car through grass, my gamepad makes rubmle as usual. But after I stop car, gamepad continues make rumble 5-10 seconds then stops. While gamepad make rumble I tried go to main menu, but rumble didnt stop. I tried change bluetooth latency, change rumble strength - nothing changed. If I plug gamepad via USB - rumble is fine.
Expected Behavior
Rumble stops after car stops
System Information
Controller and Bluetooth Information
xpadneo-lsusb.txt
xpadneo-dmesg.txt
xpadneo-btmon.txt
Additional Context
Sorry for my english
The text was updated successfully, but these errors were encountered: