kakra
commented
3 years ago Welcome to our community! This is an excellent example of a bug report and well done.
This report has a few interesting aspects but I'm not quite sure when we are looking at xpadneo alone and can be sure of it. But the interesting part is that you found the left stick being involved. What about the right stick?
Thanks to a donation from the community, I'm having the XBE2 controller, too. The current believing is that turning off rumble seems to work around the firmware lockup of the controller. But even back during development of XB1S controller support, this bug looked like the stick may be involved because I was sometimes seeing only the sticks freezing on some value while the buttons continued to work for some seconds.
About your battery reporting issue: Is this with xpadneo? Because to me it looks like the battery is correctly identified as Play'n'Charge kit. Your dmesg also shows it working:
[482252.402942] xpadneo 0005:045E:0B05.000C: fixing up report size
[482252.402945] xpadneo 0005:045E:0B05.000C: fixing up Rx axis
[482252.402947] xpadneo 0005:045E:0B05.000C: fixing up Ry axis
[482252.402948] xpadneo 0005:045E:0B05.000C: fixing up Z axis
[482252.402949] xpadneo 0005:045E:0B05.000C: fixing up Rz axis
[482252.402951] xpadneo 0005:045E:0B05.000C: fixing up button mapping
[482252.403967] xpadneo 0005:045E:0B05.000C: battery detected"battery detected" means that we received the first battery report from the controller and could identify the bits correctly.
[482273.058955] xpadneo 0005:045E:0B05.000C: pretending XB1S Windows wireless mode (changed PID from 0x0B05 to 0x02E0)
[482273.058958] xpadneo 0005:045E:0B05.000C: enabling compliance with Linux Gamepad Specification
[482273.059073] input: Xbox Elite Wireless Controller as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0/bluetooth/hci0/hci0:11/0005:045E:0B05.000C/input/input43
[482273.059685] xpadneo 0005:045E:0B05.000C: input,hidraw0: BLUETOOTH HID v9.03 Gamepad [Xbox Elite Wireless Controller] on 28:c2:dd:de:82:63
[482273.059690] xpadneo 0005:045E:0B05.000C: controller quirks: 0x00000018
[482274.049945] xpadneo 0005:045E:0B05.000C: Xbox Elite Wireless Controller [98:7a:14:55:31:55] connected
[482282.909308] xpadneo 0005:045E:0B05.000C: battery registered"battery registered" means we have identified the battery type and registered it with the power supply subsystem of Linux. From here on it's up to user space to make any use of it.
[483985.613673] xpadneo 0005:045E:0B05.000C: shutting down"shutting down" is also a battery report and will be sent when the controller automatically turns off due to depleted battery or idle timeout (no input in 10-15 minutes), or because you forced it to shut down by holding the Xbox logo button. It will (and can) never be shown if Bluetooth disconnected because we wouldn't read a battery event then.
So if your controller input froze between the last two lines, it'll mean that Bluetooth is still functional. That would also explain why the Bluetooth stack doesn't disconnect because of transmit/receive timeout.
I've already seen two different pictures:
-
In the first case, the controller crashes/locks up, the Bluetooth connection breaks, after a timeout of 30s, the controller restarts, re-connects, and the controller becomes available in most games again (some games just don't correctly support hot plugging). It will be back working after 30-60s. In this case, the controller seems to know it crashed due to rumble and no longer rumbles but the connection will be stable now throughout the game.
-
In the second case, the controller ceases sending any more input, and rumble may "freeze" in time. But Bluetooth doesn't timeout, so the Bluetooth handler in the controller firmware seems to be still responsive. But some internal state locked up and no longer generates input events. To get the controller back, you may need to power-cycle it, and games usually do not re-detect it afterwards. That's probably because the kernel doesn't unregister the old input device before initializing the new one, and then it seems like a different device to games. I'd expect the following observation here: You're turning the controller off and back on but the kernel doesn't notice that because the Bluetooth connection didn't break. Now, a new device will appear and initialize a new driver instance, and just the very same moment it will tear the old driver instance down - but it already has a new instance ID now.
I've also seen the following behavior: Run jstest and generate a continuous stream of input events by circling either one or the other stick smoothly. With some patience this also works with the triggers (tho, a lot more difficult). You may see that jstest suddenly stops seeing any updates to the reported values. Stop movement, and 1s later it will be back with reporting values. That can be easily repeated. If you're watching btmon at the same time, you'll see that the controller stops sending data to us. So this is a firmware problem, and I'm pretty sure it comes from the same origin as your problem. Rumble isn't involved at all here. Interestingly, you may no longer be able to reproduce this after rebooting the controller or re-pairing Bluetooth.
To clear some things up:
If you're using xow, you're not using the Bluetooth connection. xpadneo won't be involved here, it cannot see the controller. The same is true vice-versa: xow doesn't handle Bluetooth but only the dongle connection.
If you're using USB, you will be using the xpad driver. Neither xow nor xpadneo support the USB wired connection of the controller: xow may probably support it because the wireless dongle protocol and wired USB protocol are very similar but the Bluetooth protocol is completely different: Bluetooth uses HID, while dongle and USB use very similar variants of GIP - if not identical protocols.
So first question would be: Did your games use rumble effects? If yes, could you disable rumble and see if behavior changes? You can use the module parameter rumble_attenuation=100 to effectively stop the driver from sending rumble commands to the controller at all.
After all, we are back again at some very weird timing bug or firmware race of the controller which only occurs in wireless mode (either one) but not in wired mode. For XB1S this was fixed by keeping intervals between rumble commands above 10ms. But that doesn't seem to be a work-around for XBE2: For me it usually crashes at the first rumble packet no matter which timing is used. I wonder what the problem is because I don't think it happens with Windows or Android. Both systems use a different kernel-side Bluetooth implementation. So the actual Bluetooth protocol implementation may matter here (which would still be a bug in the controller firmware: we should not be able to crash it by sending packets in some different order or timing). At least the Windows driver also keeps rumble command timings above intervals of 10ms, which by the way is the timing resolution of the rumble motor programming interface.
Next question would be: Does xow show the same problem - tested with and without rumble?
I don't expect the USB connection to show any problems, so we probably don't need to test that. Also, it's a different implementation of the protocol and we would be comparing apples and oranges. By that, it even doesn't work as a reference to compare. For xow it would but not for xpadneo.
About the paddle buttons: As far as I found out, these are mapped to events in hardware. While we can see 4 bits that show the paddle state, we cannot tell them apart from A,B,X,Y because in default profile 0 (all profile LEDs are off), it'll be mapped to A,B,X,Y in hardware: The protocol shows P1-P4 bits set to 1 along with A,B,X,Y bits set to 1, so we cannot know the real state of A,B,X,Y when P1-P4 shows up. When switching to a different profile, we don't see any of those bits. So it seems like P1-P4 are only indicated by bits if they are programmed. The HID descriptor shows that there's a programming command to upload macros to the controller. I didn't yet decode that or record any programming from a Windows VM to reverse engineer it. But that's planned for v0.10 or v0.11. Currently, we will detect that the profile switch button was used and which profile number it activated. Current master branch has the proper commits in place for that. My next commit will be to detect the position of the pressure limiter for the triggers. So yes, the paddles will map to A,B,X,Y and that's implemented in hardware for profile 0, it's not a driver thing. If you switch to profile 1-3, the paddles will become invisible to xpadneo currently, not sure about xow because that is using GIP instead of HID.
solystm
maharifu
Version of xpadneo
v0.8 (I also have xow 0.5-17-gaf5b9d4 installed, but the behavior is the same with xpadneo alone, xow alone, and xpadneo with xow)
Severity / Impact
It completely prevents the controller from being used through Bluetooth for more than between 5 minutes and an hour, depending on some factors I'm not sure on. After that period it locks up and needs to be powered off and then reconnected again. Games generally need to be restarted in order to re-detect it.
Describe the bug
The controller connects fine and works well, reporting battery, all buttons working, even the underpad triggers (though that may be xow's doing?) I start playing a game (tested with Trials of Mana and Streets of Rage 4 primarily) and it's detected and works as expected in the game. However, after a period of time somewhere between 5 minutes (at the earliest) and about an hour (at the latest) the controller will lock up and stop working until it's powered off (hold Xbox button) and then powered back on again.
By "lock up" I mean the controller's input 'sticks' on whatever it was doing when the bug occurred. So, for example, if i was holding right on the left analog, it would continue holding right even if i let go entirely. Other buttons cease to register at this time. For example, pressing ABXY gets no input in game or in a controller calibration utility, when both work fine normally. The controller calibration utility will report the last state (for example, the left analog being held to the right) and no longer update. The controller stays connected to bluetooth from what i can see.
Steps to Reproduce
Connect up, start a game, and play. Eventually, it will drop the connection. With that said, it seems to be associated more with left analog stick inputs. It's never actually locked up while the left analog was neutral. That includes an extended session of Streets of Rage 4 only using the dpad, but when I switched to the left analog it locked up pretty much immediately. Given the wide range in the amount of time that passes it's difficult to say if it's related but it sure seems that way.
Expected behavior
It should continue to work normally without doing that :)
Screenshots/Gifs
I could take a video of me giving the pad inputs while nothing is registered by a game/controller calibration tool, but I'm not sure that would be terribly useful.
System information
Controller and Bluetooth information
xpadneo-btmon.txt xpadneo-dmesg.txt xpadneo-lsusb.txt
Additional context
Issue was reproduced on a desktop using Asus X99 Deluxe built-in bluetooth also reproduced on a Dell XPS13, both computers on Fedora 32 and roughly up to date with updates. Attempted to reproduce issue on a Windows 10 laptop, it didn't happen there but given the intermittent nature I wasn't certain it wouldn't.
I saw some other strange behavior out of the controller, including it not reporting the battery level at all even in Windows, so i ended up returning it for a second controller which works better (reports battery for instance) but exhibits this same behavior. I THINK it behaved the same way both on the firmware the controller had out of the box as well as the most up-to-date firmware (as per the Xbox Accessories app on Windows) but it definitely happens on the up-to-date one.
This only occurs on Bluetooth, I haven't had it happen with USB direct connection or the wireless adapter dongle. (I may not have given it enough time with the dongle, though.)
I'm not sure the best option for this, but capturing data while the issue occurs might help. I can't make it happen on command so I'd need to be using the controller over a period of time while logging.