Skip to content
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

Open
jeffkeller87 opened this issue Dec 20, 2020 · 53 comments
Open

Model 1904 wireless dongle timeouts/disconnects when idle #144

jeffkeller87 opened this issue Dec 20, 2020 · 53 comments

Comments

@jeffkeller87
Copy link

jeffkeller87 commented Dec 20, 2020

Model Number (as printed on box): "1904, 1790"
xow version: 0.5

The 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.

$ lspci | grep USB
03:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] X370 Series Chipset USB 3.1 xHCI Controller (rev 02)
26:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host Controller
29:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller

I have tried plugging the controller into:

  • USB 2.0 and 3.0 ports on the back motherboard (I assume this is the first controller listed above)
  • A USB 3.0 hub, which in turn is plugged into the back of the motherboard
  • Front-panel USB 2.0 and 3.0 ports (I assume this is the third controller listed above)

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:

$ sudo systemctl status xow
● xow.service - Xbox One Wireless Dongle Driver
     Loaded: loaded (/etc/systemd/system/xow.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2020-12-20 14:18:49 EST; 4min 11s ago
   Main PID: 5905 (xow)
      Tasks: 4 (limit: 38366)
     Memory: 2.0M
     CGroup: /system.slice/xow.service
             └─5905 /usr/local/bin/xow

Dec 20 14:22:06 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:06 INFO  - Controller '1' connected
Dec 20 14:22:07 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:07 INFO  - Device announced, product id: 0b12
Dec 20 14:22:07 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:07 INFO  - Serial number: 09711987454032
Dec 20 14:22:08 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:08 INFO  - Battery level: 2
Dec 20 14:22:33 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:33 INFO  - Controller '1' disconnected
Dec 20 14:22:42 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:42 INFO  - Controller '1' connected
Dec 20 14:22:42 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:42 INFO  - Device announced, product id: 0b12
Dec 20 14:22:42 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:42 INFO  - Serial number: 09711987454032
Dec 20 14:22:43 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:43 INFO  - Battery level: 2
Dec 20 14:22:58 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:58 INFO  - Controller '1' disconnected

$ dmesg -w
# ...
[ 1756.079810] input: Xbox One Wireless Controller as /devices/virtual/input/input67
[ 1779.732696] input: Xbox One Wireless Controller as /devices/virtual/input/input68
[ 1826.222612] input: Xbox One Wireless Controller as /devices/virtual/input/input69
[ 1864.723501] input: Xbox One Wireless Controller as /devices/virtual/input/input70
[ 1886.227131] input: Xbox One Wireless Controller as /devices/virtual/input/input71
[ 1916.229892] input: Xbox One Wireless Controller as /devices/virtual/input/input72
[ 1947.973437] input: Xbox One Wireless Controller as /devices/virtual/input/input73
[ 1983.711712] input: Xbox One Wireless Controller as /devices/virtual/input/input74
[ 2008.183596] input: Xbox One Wireless Controller as /devices/virtual/input/input75
[ 2032.042565] input: Xbox One Wireless Controller as /devices/virtual/input/input76
[ 2078.121966] input: Xbox One Wireless Controller as /devices/virtual/input/input77
[ 2129.935380] input: Xbox One Wireless Controller as /devices/virtual/input/input78
[ 2170.485511] input: Xbox One Wireless Controller as /devices/virtual/input/input79
[ 2194.651219] input: Xbox One Wireless Controller as /devices/virtual/input/input80
[ 2216.052670] input: Xbox One Wireless Controller as /devices/virtual/input/input81
[ 2236.020467] input: Xbox One Wireless Controller as /devices/virtual/input/input82
[ 2287.936289] input: Xbox One Wireless Controller as /devices/virtual/input/input83
[ 2307.699296] input: Xbox One Wireless Controller as /devices/virtual/input/input84
[ 2338.930774] input: Xbox One Wireless Controller as /devices/virtual/input/input85
[ 2359.615096] input: Xbox One Wireless Controller as /devices/virtual/input/input86
[ 2383.269234] input: Xbox One Wireless Controller as /devices/virtual/input/input87

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.

@jeffkeller87
Copy link
Author

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?

@medusalix
Copy link
Owner

@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.
There's a PR (#142) that apparently fixes those issues. You might want to give it a try.

@jeffkeller87
Copy link
Author

Thanks for the tip @medusalix. Unfortunately, that PR did not fix the issue for me. I commented my results there.

@yoyossef
Copy link

yoyossef commented Dec 22, 2020

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.

@jeffkeller87
Copy link
Author

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 xow service between testing different ports. So something for others to try.

@alkazar
Copy link

alkazar commented Dec 31, 2020

@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.

@jeffkeller87
Copy link
Author

@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.

@alkazar
Copy link

alkazar commented Dec 31, 2020

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.

@TheCraiggers
Copy link

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.

@kakra
Copy link
Contributor

kakra commented Jan 10, 2021

@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.

@jeffkeller87
Copy link
Author

jeffkeller87 commented Jan 12, 2021

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.

Reporting back with more info now that I'm on an MSI B550 Tomahawk motherboard:

$ lspci | grep USB
02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43ee
2d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller

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.

product_2_20200520165819_5ec4f12b5dc4b

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.

$ dmesg -w
[   48.492762] input: Xbox One Wireless Controller as /devices/virtual/input/input34
[   77.173289] input: Xbox One Wireless Controller as /devices/virtual/input/input35
[   98.071499] input: Xbox One Wireless Controller as /devices/virtual/input/input36
[  290.283890] input: Xbox One Wireless Controller as /devices/virtual/input/input37
[  376.708101] input: Xbox One Wireless Controller as /devices/virtual/input/input38
[ 1250.907928] input: Xbox One Wireless Controller as /devices/virtual/input/input39
# controller shuts down due to inactivity around 1850s
# I turn the controller back on
[ 2325.424310] input: Xbox One Wireless Controller as /devices/virtual/input/input40
[ 2525.107803] input: Xbox One Wireless Controller as /devices/virtual/input/input41
[ 2743.736879] input: Xbox One Wireless Controller as /devices/virtual/input/input42
[ 2779.577636] input: Xbox One Wireless Controller as /devices/virtual/input/input43
[ 2894.985140] input: Xbox One Wireless Controller as /devices/virtual/input/input44

@kakra
Copy link
Contributor

kakra commented Jan 12, 2021

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?

@jeffkeller87
Copy link
Author

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.

@medusalix
Copy link
Owner

medusalix commented Jan 15, 2021

Wasn't there something in the past that mentioned Wifi channel hopping of the dongle and how the controller may disconnect then?

I believe channel hopping is implemented in the firmware of the dongle and the controller. The driver just supplies the available channel candidates.

Or is it 2.4 GHz that the dongle is using? @medusalix Do you know?

@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 Enable2Dot4GHz string in the binary of Microsoft's GIP driver, so I'm pretty sure there's a way to force the dongle to use 2.4 GHz (I'd really like to know how to enable it).

@kakra
Copy link
Contributor

kakra commented Jan 15, 2021

I wonder if it could be disassembled, tho that's probably not allowed by the TOS supplied with the driver.

@movisman
Copy link

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.

@medusalix
Copy link
Owner

We'll have to wait until Microsoft releases a firmware update.

@movisman
Copy link

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!

@Bloodaxe95
Copy link

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?

@kakra
Copy link
Contributor

kakra commented Aug 11, 2021

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).

@Pieman711
Copy link

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.

@djolker
Copy link

djolker commented Sep 6, 2021

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

@samAnnisBrown
Copy link

+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!

@silvannn
Copy link

Hi, I have the same issue. 1914 is constantly disconnecting and connecting but...
I am just starting my journey with RetroPie and instead of installing it by myself I used ready ISO image which I downloaded from arcadepunk.com. I have checked two images created by RickDangerous for RaspberryPi 4 and on one of them my dongle and controller is working perfectly. No idle disconnection. On second image I have that issue. In both cases I installed xow drivers the same way. So now I have pendrive with retropie where controller is working fine and ssd with retropie where I am experiencing this issue. I am a noob and I do not know how to check differences between those versions but it looks like there is no problem with xow but with operation system itself. Some settings needs to be changed or something is missing. My 1914 is updated and working perfect on PC.

@djolker
Copy link

djolker commented Sep 15, 2021

I'm curious if maybe there's two separate issues at play here that look very similar:

  1. The controller is idle in which case bluetooth low energy mode trys to turn on and causes the disconnect.
  2. Something unrelated to BLE causing disconnects mid use

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

@OriginLegend
Copy link

OriginLegend commented Sep 17, 2021

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:
https://github.com/medusalix/xow/blob/master/dongle/dongle.cpp#L272

As a result, I added a build-flag to disable this behavior: EMPTY_PACKET_DISCONNECT
Pull-Request: #185

If you want to test it make sure you clean your workspace and rebuild with this flag:
make clean
make BUILD=RELEASE EMPTY_PACKET_DISCONNECT=0

Let me know if this resolves the issues for y'all as well

@samAnnisBrown
Copy link

Thanks @OriginLegend - initial testing didn’t solve this for me.

  • Stopped and disable xow service
  • Cleaned workspace in existing xow dir
  • Cloned your fork in new dir
  • Rebuilt with EMPTY_PACKET_DISCONNECT=0 flag
  • Reinstalled and started service

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.

@OriginLegend
Copy link

OriginLegend commented Sep 18, 2021

@samAnnisBrown Thanks for the feedback - do you have a model 1914 controller as well?
I am trying to experiment with other solutions which might help, but so far I don't have any new things to test (all changes I have experimented with cause instability - crashing, etc).

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.

@samAnnisBrown
Copy link

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.

@silvannn
Copy link

silvannn commented Oct 7, 2021

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.

@kakra
Copy link
Contributor

kakra commented Oct 7, 2021

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.

@Bloodaxe95
Copy link

Bloodaxe95 commented Oct 23, 2021

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?

@OriginLegend
Copy link

@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

@Bloodaxe95
Copy link

@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 😄

@samAnnisBrown
Copy link

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.

@OriginLegend
Copy link

@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:
https://github.com/OriginLegend/xow

If we get it working I will add it to my open pull-request:
#185

OriginLegend added a commit to OriginLegend/xow that referenced this issue Oct 23, 2021
@OriginLegend
Copy link

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
It is built and tested the same way, just includes a lot more debug information while running for my context what is going on exactly.

You can follow these steps to update the version running on your computer:

To uninstall the service:

sudo systemctl stop xow
sudo systemctl disable xow
sudo make uninstall

To remove the currently cloned repo (or you can put it in a different directory):

cd ..
rm -r xow

Clone the forked repository (testing branch):

git clone -b testing https://github.com/OriginLegend/xow.git
cd xow

Build the new version with debugging added:

make BUILD=RELEASE EMPTY_PACKET_DISCONNECT=0
sudo make install
sudo systemctl enable xow
sudo systemctl start xow

Once the controller disconnects, you can view the last messages from the service and attach them to this issue by doing the following:

sudo systemctl status xow

# I believe you can also increate the line-count by doing the following (would be more helpful)
sudo systemctl status xow -n 50

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. 😄

@samAnnisBrown
Copy link

samAnnisBrown commented Oct 26, 2021

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 master of your fork. Should I have pulled from frequent-disconnects instead? (I see a later commit?).

Pulling from master at the time, there were no errors thrown during build with the EMPTY_PACKET_DISCONNECT=0 flag, so I assumed the required code was present.

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!

@samAnnisBrown
Copy link

samAnnisBrown commented Oct 26, 2021

I think I'm an idiot - I just compared code and can clearly see master doesn't contain the required code in your fork to resolve disconnects - I'll need to pull from frequent-disconnects. I figured it would throw an error during build if the flag didn't exist, but maybe not?

Let me try that branch and get back to you - but based off my testing earlier today, I suspect it's going to work!

@samAnnisBrown
Copy link

Ok, I’m an idiot - just installed from ‘frequent-disconnects’ instead of ‘master’ and it resolved my problem.

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:

git clone -b testing https://github.com/OriginLegend/xow.git

I put:

git clone -b frequent-disconnects https://github.com/OriginLegend/xow.git

@Bloodaxe95
Copy link

@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!!

@OriginLegend
Copy link

@samAnnisBrown @Bloodaxe95

Thanks for all the feedback, I am very happy to hear that the frequent-disconnects branch works for you all!
I'll leave my testing branch there just in-case the issue presents itself again we have the debugging capabilities.
Aside from that, we'll just wait for the pull-request to be merged.

@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 frequent-disconnects specifically for functionality. Might be my bad since I have not done a GitHub-specific pull-request before, so I wasn't aware of conventions (i.e. if master-branch in forked repo is typically used).

@samAnnisBrown
Copy link

Not aware of conventions myself @OriginLegend , just made the perhaps incorrect assumption it would be in master.

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.

@Pieman711
Copy link

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!

@OriginLegend
Copy link

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 0b12 so I will automatically enable the fix for this id.
But I will also leave in the build-flag for different controllers in-case they need this as well.

Logs showing the product id from original issue poster (matches with my own):

Dec 20 14:22:06 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:06 INFO  - Controller '1' connected
Dec 20 14:22:07 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:07 INFO  - Device announced, product id: 0b12
Dec 20 14:22:07 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:07 INFO  - Serial number: 09711987454032
Dec 20 14:22:08 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:08 INFO  - Battery level: 2

@XirXes
Copy link

XirXes commented Oct 31, 2021

I am assuming that the product id everyone is using is 0b12 so I will automatically enable the fix for this id. But I will also leave in the build-flag for different controllers in-case they need this as well.

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 02ea which I'm pretty sure is the the same ID from the old firmware version.

Update, works ok, but crashed after about an hour of play.

Oct 31 16:54:04 nexus xow[62239]: 2021-10-31 16:54:04 INFO  - Controller '1' connected
Oct 31 16:54:04 nexus xow[62239]: 2021-10-31 16:54:04 INFO  - Device announced, product id: 02ea
Oct 31 16:54:04 nexus xow[62239]: 2021-10-31 16:54:04 INFO  - Serial number: 02600214093643
Oct 31 16:54:06 nexus xow[62239]: 2021-10-31 16:54:06 INFO  - Battery level: medium
Oct 31 17:04:44 nexus xow[62239]: 2021-10-31 17:04:44 INFO  - Controller '2' connected
Oct 31 17:04:44 nexus xow[62239]: 2021-10-31 17:04:44 INFO  - Device announced, product id: 02ea
Oct 31 17:04:44 nexus xow[62239]: terminate called after throwing an instance of 'InputException'
Oct 31 17:04:44 nexus xow[62239]:   what():  Error adding key code: Invalid argument
Oct 31 17:04:45 nexus systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Oct 31 17:04:45 nexus systemd[1]: xow.service: Failed with result 'signal'.

@medusalix
Copy link
Owner

medusalix commented Nov 2, 2021

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.
Properly fixing this issue would require analyzing the USB packets sent between the Windows driver and the dongle. Capturing those packets can be done using Wireshark. I think a ~30 min capture should be sufficient to find out what the Windows driver does to prevent the controllers from disconnecting.
Feel free to contact me on Discord if you need assistance with using Wireshark.

@XirXes
Copy link

XirXes commented Nov 2, 2021

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.
https://drive.google.com/file/d/18HpBU6tkL1qVd8MP9ng4U07NZGAqjemt/view?usp=sharing

@25minutes
Copy link

25minutes commented Nov 5, 2021

@OriginLegend
I'm trying to compile your code with static libraries on Ubuntu 18.04 LTS. I have searched the web and tried to modify Makefile by adding "-static", then it failed to compile with a lot of "undefined reference" errors. Below are the changes I made:

xow: $(OBJECTS)
$(CXX) $(LDFLAGS) -o $@ $^ $(LDLIBS) -static

%.o: %.cpp
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c -o $@ $< -static

As I have limited skills on coding, I couldn't work this out. I'd appreciate if anyone experienced could give me some advice.

@Untz64
Copy link

Untz64 commented Dec 23, 2021

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 DEBUG to see if there was any more relevant info, see below:

Dec 23 22:39:35 retropie xow[1510]: 2021-12-23 22:39:35 INFO  - Battery level: medium
Dec 23 22:39:55 retropie xow[1510]: 2021-12-23 22:39:55 INFO  - Controller '2' connected
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 INFO  - Device announced, product id: 0b12
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 DEBUG - Firmware version: 5.9.2709.0
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 DEBUG - Hardware version: 1032.1.1.1
Dec 23 22:39:56 retropie xow[1510]: terminate called after throwing an instance of 'InputException'
Dec 23 22:39:56 retropie xow[1510]:   what():  Error adding key code: Invalid argument
Dec 23 22:39:56 retropie systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Dec 23 22:39:56 retropie systemd[1]: xow.service: Failed with result 'signal'.

Not sure why it's seeing the same controller as a "second" controller.

@emilsz
Copy link

emilsz commented Jan 10, 2022

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.
Controller firmware version: 5.9.2709.0
Will see if I can downgrade the firmware in the mean time.

@C0nvert
Copy link

C0nvert commented Feb 20, 2022

Same Problem for me

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 DEBUG to see if there was any more relevant info, see below:

Dec 23 22:39:35 retropie xow[1510]: 2021-12-23 22:39:35 INFO  - Battery level: medium
Dec 23 22:39:55 retropie xow[1510]: 2021-12-23 22:39:55 INFO  - Controller '2' connected
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 INFO  - Device announced, product id: 0b12
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 DEBUG - Firmware version: 5.9.2709.0
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 DEBUG - Hardware version: 1032.1.1.1
Dec 23 22:39:56 retropie xow[1510]: terminate called after throwing an instance of 'InputException'
Dec 23 22:39:56 retropie xow[1510]:   what():  Error adding key code: Invalid argument
Dec 23 22:39:56 retropie systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Dec 23 22:39:56 retropie systemd[1]: xow.service: Failed with result 'signal'.

Not sure why it's seeing the same controller as a "second" controller.

@reapingbearpig
Copy link

reapingbearpig commented Feb 2, 2024

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 {sudo systemctl status xow} and received this back.. im not sure where to go from here. any help understanding this error is appreciated. i think i have to stop the Prevent the mt76x2u driver from loading but im not sure how to do this...

xow.service - Xbox One Wireless Dongle Driver
     Loaded: loaded (/etc/systemd/system/xow.service; enabled; preset: enabled)
     Active: failed (Result: core-dump) since Thu 2024-02-01 22:23:28 EST; 8min ago
   Duration: 13min 25.314s
    Process: 1358 ExecStart=/usr/local/bin/xow (code=dumped, signal=ABRT)
   Main PID: 1358 (code=dumped, signal=ABRT)
        CPU: 20ms

Feb 01 22:10:02 dex-V1-04 systemd[1]: Started xow.service - Xbox One Wireless Dongle Driver.
Feb 01 22:10:07 dex-V1-04 xow[1358]: 2024-02-01 22:10:07 INFO  - xow v0.5-36-gd335d60 ©Severin v. W.
Feb 01 22:10:07 dex-V1-04 xow[1358]: 2024-02-01 22:10:07 INFO  - Waiting for device...
Feb 01 22:23:27 dex-V1-04 xow[1358]: terminate called after throwing an instance of 'UsbException'
Feb 01 22:23:27 dex-V1-04 xow[1358]:   what():  Error setting configuration: LIBUSB_ERROR_BUSY
Feb 01 22:23:28 dex-V1-04 systemd[1]: xow.service: Main process exited, code=dumped, status=6/ABRT
Feb 01 22:23:28 dex-V1-04 systemd[1]: xow.service: Failed with result 'core-dump'.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests