-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model 1904 wireless dongle timeouts/disconnects when idle #144
Comments
Could it be that even though I have tried using the USB 2.0 ports in a couple locations, that because the underlying USB controller on the motherboard is USB 3.x, that I am actually running into the power management issues described in the README? |
@jeffkeller87 It doesn't look like the problem is caused by your USB controller at all. It seems like the newer Series X controller has that exact same issue on Windows too. |
Thanks for the tip @medusalix. Unfortunately, that PR did not fix the issue for me. I commented my results there. |
I confirm this issue with my Xbox Series Controller (white one), one thing different though is that it's sometimes not reconnecting the controller after it gets disconnected. Sometimes I'm able to reconnect it by pushing the Xbox button and it's not that big of a deal, but after a few times my controller won't turn on again, the led immediately turns off (instead of repeatedly blinking) as I stop pushing the Xbox button. And the only solution to that is for me to put out the batteries, and I have to wait for the controller to reset itself for ~2-3 minutes, maybe my batteries are at fault, I'll check on that. It feels very unstable and unreliable overall unfortunately, I'd be glad to help in any way. |
So this issue has seemingly gone away for me.... the only material change I can think of has been changing the ports in which my USB hub is connected to the motherboard and also rebooting. Previously, I was just restarting the |
@jeffkeller87 are you using this fix #142 or a release build? I am also experiencing this issue. The timeout doesn't seem to be consistent. I have seen as short as 15 seconds and as long as 45 seconds. I am using xow 0.5. |
@alkazar I am back to using the 0.5 release build and the issue has still not returned for me. Aside from what has already been mentioned, the only other thing I can think of that could have contributed to the fix was that I booted into my Windows partition. I did not use the controller while in Windows, but I suppose it is possible that a firmware update was applied by Windows Update automatically? When I was having the issue, I did notice the timeout could be inconsistent as well, 15-45 seconds sounds about right. |
Switching USB ports did not seem to help. I am using the dongle I bought for use with the Xbox One S controller. I wonder if the dongle needs a firmware upgrade to work with the new controllers properly. |
Switching entire computers hasn't helped, never mind USB ports. Meanwhile, my older xbox controller (no share button, microUSB) works just fine. As medusa said, people are having problems in windows as well so I don't think this is even a xow issue. However, I'm worried that any fix released from MS will be difficult / impossible to apply without a windows computer or xbox game console, as it looks like it may involve a firmware update for the controllers. I don't know of a way to update them on Linux. |
@TheCraiggers You can download an eval ISO of Windows 10 directly from Microsoft, install it into a VM, and run the Xbox accessories app from there to update the gamepad. You should do that with the dongle, tho, because the controller will reboot into a firmware download mode which would disconnect it from USB (and thus disable USB pass-thru to the VM) - using the dongle, the USB connection will be kept alive as only the controller reboots. |
Reporting back with more info now that I'm on an MSI B550 Tomahawk motherboard:
I had to re-pair the controller with the dongle and then proceeding to try every USB port on the back of the motherboard (rebooting in between) and found that the lone USB 2.0 port (not counting the BIOS flashback port) gave me the best results. Interestingly, I was still experiencing disconnects when using the dongle with this port, but they were relatively infrequent. I turned the controller on and just let it sit without any input to see what happened. Disconnects happened at ever increasing intervals until the interval was long enough that the controller powered down due to inactivity (30 minutes I think). Repeating the test, I still had disconnects but they continued to happen fairly infrequently. TLDR; My earlier experience where I claimed the disconnects had stopped may have just been a case where the disconnects were happening quite far apart. Far enough apart that input activity from normal use (playing a game) would keep the connection alive. Not great, but a lot less annoying than a disconnect every 20-30 seconds on inactivity.
|
Wasn't there something in the past that mentioned Wifi channel hopping of the dongle and how the controller may disconnect then? Do you have a lot of 5 GHz Wifi around? Maybe try turning 5 GHz off in your Wifi network for a test... Or is it 2.4 GHz that the dongle is using? @medusalix Do you know? |
In my case there are no 5 GHz WiFi networks in the vicinity, only two 2.4 GHz networks, and I am still experiencing intermittent disconnects. |
I believe channel hopping is implemented in the firmware of the dongle and the controller. The driver just supplies the available channel candidates.
@kakra I'm pretty sure the firmware defaults to 5 GHz, although xow is configuring both 2.4 and 5 GHz channels. There's a |
I wonder if it could be disassembled, tho that's probably not allowed by the TOS supplied with the driver. |
Just to confirm, I see this exact issue on my MiSTer (linux). I had chance to test an Xbox Series X controller (1914) with it, and it works great except for this idle disconnect/reconnect thing which is quite bizarre. My firmware is fully up to date on the controller side of things. Mine disconnects and reconnects by itself in 3-4 seconds, I don't need to power it back on or anything like that. Timing can vary but seems to be around 25-30 seconds initially when left idle. My Xbox One controllers (1708) do not exhibit this behaviour - they have worked robustly on RetroPie for a long while now. They also work great on my MiSTer. For reference, I am using the slim wireless dongle. There are a lot of threads all over the place about a similar issue with the controller disconnecting for people, and MS are still working on it - but it is not resolved yet. I hope this is the same issue, although curiously, when using the dongle in Windows, it doesn't seem to do the disconnect/reconnect thing - but I haven't tested in detail. |
We'll have to wait until Microsoft releases a firmware update. |
No worries. I haven't managed to make it happen in Windows yet, but only did a little more testing today. Certainly seems like an MS thing though, so will hang tight and test again further once they release a firmware update for the controller. It's very easy to replicate on my MiSTer, intervals between each idle desync/resync can vary but ultimately it still happens on every boot and the first desync/resync is "usually" only after 30 seconds or so of idle time. Thanks! |
I'm not seeing any of the disconnects when I'm connected to a Windows PC, and I've updated the controller to the latest firmware. This issue is still present, and it's annoying the crap out of me. Is there anything a non-coder can do to help finding and publishing a solution to this? |
Maybe it could be worth it capturing the USB traffic from connect until the unexpected disconnect, then do the same in Windows, and compare both. If Windows does something different, it probably sends intermittent commands to the dongle which Linux doesn't - or reacts to some other events that xow does not support/care about. You should probably not touch any controls while capturing the USB traffic to keep the protocol noise low. But I cannot help with how to correctly capture the traffic in both OS - but I'm pretty sure @medusalix already posted it somewhere (maybe in Discord only). |
Just to confirm I'm getting exactly the same issue. 1914 controller with the wireless dongle. I'm playing through steamlink and the disconnect/reconnect cause a load of lag and glitches that can often stop the whole game. I'll try and look through the discord, but if someone can point me to a bit of a guide on how to monitor USB traffic, or anything else useful, then I'll have a stab at it and feedback my findings. |
Having a very similar experience to what's being described here. I use a 1537 and 1914 controller with my 1790 Wireless Adapter The 1537 works very well for the most part (doesn't disconnect early), but the 1914 will start to disconnect cycle after about 15 to 30 seconds (sometimes even less) of idle time, or occasionally just straight up in the middle of usage (very rarely for that though) I've noticed the issue is worse when they are both attached to the wireless adapter, even causing the 1537 model to disconnect cycle occasionally. Happy to assist in any way |
+1 Same issue on latest release of Rasbian. Using 1914 with wireless dongle since Bluetooth seemed impossible (pairing issues). Dongle works a charm outside the connection issues. Same 15-30 sec idle disconnect. Wouldn’t bother me that much except I’m using with RetroPie, and the hotkey stops working after a disconnect, meaning i can no longer save states or exit emulators without a reboot. Extremely frustrating and keen for a fix or workaround if someone finds one! |
Hi, I have the same issue. 1914 is constantly disconnecting and connecting but... |
I'm curious if maybe there's two separate issues at play here that look very similar:
The title of this thread has to do with the controller timeing out when it idles, but it seems like a few of us are having disconnect problems in the middle of use. I've noticed even my older controller will begin rapidly disconnecting and reconnecting after about an hour or two of constant play |
Not sure if this issue is related to one I am facing (seems like it is). For me the issue was the empty-packet received by the driver results in an automatic disconnect: As a result, I added a build-flag to disable this behavior: EMPTY_PACKET_DISCONNECT If you want to test it make sure you clean your workspace and rebuild with this flag: Let me know if this resolves the issues for y'all as well |
Thanks @OriginLegend - initial testing didn’t solve this for me.
After this I needed a reboot before controllers would connect. Stillhad a disconnect within 30 seconds of idle. Very basic testing - might spend more time on it tonight. |
@samAnnisBrown Thanks for the feedback - do you have a model 1914 controller as well? Will try to take a look on Monday too when I have more time and see if there is anything else I can try to make this work. |
A little more testing - basically just uninstalls, reboots, and rebuilds in various orders to see if anything stuck. Still getting disconnects @OriginLegend. I’ve the 1790 dongle and 1914 controllers. Thanks for your efforts - happy to test anything you might come up with. The install and testing I’m good with, but the dev is a bit out of my depth. |
Can someone look on this retropie image: https://punkwhore.com/arcadepunks/2021-2/tor/64gb-Blue.Unicorn.RPi4.Kids-Rick.Dangerous.torrent? With this image and xow installed, controller doesn't disconnect when idle. |
It may not be okay to share links to content which possibly contain copyrighted material. By the link name, this looks like the image may contain intellectual property of third parties. |
Is it possible to make a bounty on this? I really want this issue fixed, although I don't have a ton of cash to give xD But some cash is better than no cash, right? |
@Bloodaxe95 I'm happy to try to add to my own change* (which doesn't seem to work for everyone) without a bounty, but I would definitely need someone else on here (like yourself) to do some extensive back-and-forth testing since I can't reproduce this myself. I will work on a separate branch that has a lot more debug info/statements for y'all to test in the next day or so that way I can try to get more context. *See above for my current change |
I'd be happy to lend my time to test the change! I am unfortunately not very skilled with anything technical xD I'll do my best though 😄 |
Nice to see some more talk on this thread - this is still bugging me! @OriginLegend - I’m technical (Linux Admin with some dev experience). Happy to help along with @Bloodaxe95 - can provide logs or whatever you need. My problem is always time with 2 young kids, but could typically turn some testing around within 24 hours. |
@samAnnisBrown and @Bloodaxe95, Thanks, I will try to update the project with a bit more targeted logging, etc sometime later tonight or early tomorrow for testing so I can get a better idea of what exactly is going on. I am also trying to do some of my own research into what might be the issue. I completely understand on time limitations (my time can be sparse too occasionally) so no rush on testing turn-around. I will provide an update on this thread once this is done which will reference my forked repo here: If we get it working I will add it to my open pull-request: |
Apologies for the longer-than expected turn-around. I have added a branch called "testing" in my fork: https://github.com/OriginLegend/xow/tree/testing You can follow these steps to update the version running on your computer: To uninstall the service:
To remove the currently cloned repo (or you can put it in a different directory):
Clone the forked repository (testing branch):
Build the new version with debugging added:
Once the controller disconnects, you can view the last messages from the service and attach them to this issue by doing the following:
Thanks in advance, and no rush, I will check this thread periodically and investigate once I have more information and time - hopefully we can get to the root of the issue. 😄 |
You're fixing a problem for free - no need to apologise! So I did some cursory testing on this today. Installed as per your instructions - and my controllers no longer disconnect! (well, they didn't during the 5 mins I had to test - but they always disconnect within 30 seconds, so I took it as a tentative win). I went back through my command history to see how I installed your fork last time, and it was the exact same process you've outlined. The only difference was I pulled from Pulling from I've not had the time to compare code between branches, but will spend more time in the next 24 hours testing the various branches and confirming which might solve the problem! |
I think I'm an idiot - I just compared code and can clearly see Let me try that branch and get back to you - but based off my testing earlier today, I suspect it's going to work! |
Ok, I’m an idiot - just installed from ‘ Sorry for the run around. Keen to hear if this was also @Bloodaxe95 ’s issue? To be clear @Bloodaxe95, since you said you weren’t technical, I followed @OriginLegend ’s exact instructions above, but during the clone command, instead of:
I put:
|
@OriginLegend @samAnnisBrown the frequent-disconnects branch is functioning as intended. At least I've yet to see my controller DC after several minutes of no input. This is amazing, thank you so much!! |
Thanks for all the feedback, I am very happy to hear that the @samAnnisBrown I will post updated directions on that pull-request to be more explicit about how to checkout/build that branch (since it is admittedly a bit unclear), but thanks for the efforts of going back and checking the |
Not aware of conventions myself @OriginLegend , just made the perhaps incorrect assumption it would be in Reporting back after a few days use, and this is definitely solved. I've now had several long play sessions without a single drop out. Thanks so much for the fix. |
I've used it for a good few hours, including having two controllers attached for co-op. No disconnects whatsoever. Seems to have nailed it, thanks everyone! To install it using SamAnnisBrowns suggestion of git clone -b frequent-disconnects https://github.com/OriginLegend/xow.git But otherwise followed the instructions as above. Good work team! |
I am going to make one more change to the code to not require the additional build-flag (since this does seem to be a universal fix for all people with this controller). I am assuming that the product id everyone is using is Logs showing the product id from original issue poster (matches with my own):
|
I just tested this branch with a 1708 on the new beta Bluetooth LE firmware 5.11.3118.0 and its finally working correctly again. It reports as Update, works ok, but crashed after about an hour of play.
|
I'd really like to be able to replicate and fix this bug but the new firmware that @XirXes uses is unfortunately still not available in the Xbox Accessories App for Windows. |
I let it run for a bit over 30 minutes, and let it power off from inactivity. Let me know if you need any other captures on this firmware. |
@OriginLegend xow: $(OBJECTS) %.o: %.cpp As I have limited skills on coding, I couldn't work this out. I'd appreciate if anyone experienced could give me some advice. |
Mine was seemingly working fine on @OriginLegend's branch until recently. Now after about a minute of use the service crashes similarly to @XirXes, but I'm not on the same firmware. I rebuilt as
Not sure why it's seeing the same controller as a "second" controller. |
Can second this. The "frequent-disconnects" fix by @OriginLegend was sort of working for me, but the driver was crashing occasionally. Decided to upgrade the controller firmware using Windows 10 Xbox Accessories. After the upgrade, leaving the controller inactive for about a minute, xow shows that a new controller is connected and immediately crashes. |
Same Problem for me
|
Hello all!!! im here to breath life into this old thread!!! im having some related issues to this where it connects then disconnects a few seconds later and repeats this spiral infinitely. i ran command
|
Model Number (as printed on box): "1904, 1790"
xow
version: 0.5The
xow
driver works flawlessly with this controller model as long as the controller is not idle for too long (~30s). This usually isn't a problem when gaming, since the user is often sending inputs from the controller more than once per 30 seconds.However, if left to idle, the wireless connection to the dongle will disconnect, and reconnect a few seconds later. Not a huge deal, but is somewhat annoying when resuming play after a cut scene or load screen. Sometimes I just flick one of the analog sticks to keep the connection alive as a workaround.
I have tried plugging the controller into:
The only other USB header in use on my motherboard is from my NZXT X62 Kraken AIO. I assume this is the ASMedia controller listed above.
Some other logs that are useful as a sanity check:
Please let me know if there is any other information I can provide. I know there is a section in the README that mentions USB incompatibilities. I think I have successfully avoided an ASMedia USB controller, but maybe AMD controllers are also incompatible?
I will be doing another PC build in a few weeks which will take me away from this X370 motherboard and onto a B550. Will report back then as well.
The text was updated successfully, but these errors were encountered: