Xbox Wireless Adapter Driver (xow) Ready for Testing

[sofakng]

I've finished compiling and updating the Xbox Wireless Adapter Driver (xow) to work on MiSTer.

Here is the repository: https://github.com/MiSTer-devel/xow_MiSTer

For now it requires manual installation and there are installation instructions on the github page. After I receive some feedback it will be added to the official MiSTer update script. (thanks Locutus73!)

This driver should support all Xbox One and Xbox Series controllers but you might need to update the controller firmware (using the Xbox Accessories App on Windows 10 or the Xbox itself). It also works with all Xbox Wireless Adapters but the older (larger) adapters require a small change to the Linux kernel. This will be included in the next MiSTer linux kernel release (thanks Sorgelig!) but for now I have a compiled kernel available in github you can use.

I've also tested the latency of this adapter and it's really good. (6.051 ms)

Also, if you aren't aware the driver uses 5 GHz with the proprietary protocol so this should work good for those of you in congested 2.4 GHz areas.

Big thanks to Rysha/Kitrix for their help with testing and other information and a HUGE thanks to everybody contributing to MiSTer!

Please let me know if you find any bugs or have any questions.

[movisman]

This is fantastic news!
Thanks so much for putting this together, it is going to be really useful for a lot of people. And great news it will be added to the official updater script once you've had some feedback.

I will give it a test later on tonight or over the weekend and let you know how I get on.

Couple of initial questions:

1) How does one go about 'removing' the driver completely if they wish? I know you can run the xow_off.sh script to disable the service, but when you first enable it, are any other files adjusted/created as part of that process? I had a look and it doesn't look like it to me. If the user wants to remove/tidy up, is it a simple case of running the xow_off.sh script to disable, then deleting the xow and xow_init_script files from the linux directory? When it is implemented into the official updater, will there be a script or option for users to remove?

2) The optional 'compatibility' mode for USB (XOW_COMPATIBILITY=1)... it took me a moment to work out what that did, but I found there is an anchor link on the Xow github straight to the info which explains (https://github.com/medusalix/xow#configuration-issues - the bit about "Certain games do not detect wireless controllers") - maybe it is worth popping that link on your readme in the troubleshooting section, or perhaps copy/paste the info?

Thanks again for putting this together. I look forward to giving this a go.

People will be all over this as the latency using the 5ghz USB dongle is very low indeed.

[MostroW]

Thank you for working on this driver, i'm going to test it on my adapter which is a first version of it and report back if it works!

:EDIT:

Cloned the repository
Updated controller firmware to latest version available
Followed your instructions
Controller works like a charm!

Thank you so much for this wonderful contribution!

[sofakng]

Thanks for the feedback!

Please let me know if you discover any issues or problems. Thanks!

[metalfacemark]

brilliant news, thanks for this!

[JonnyTenebrous]

Amazing - I've been checking up on this since SmokeMonster mentioned it in a tweet a few months back. Really excited to see that it's arrived! Bought an Xbox Series Controller and wireless dongle specifically for use with this driver on MiSTer! Will wait for it to become "official" - thanks, and good luck with the testing!

Edit/Update: I decided I couldn't wait. Installation was easy - I followed the directions and it "just worked". I didn't even need to pair the controller to the dongle since I had already done that on my PC. Performance seems great! I don't have any proper latency testing equipment, but I put it through its paces on some sections of NES games that I find very difficult to nail if total latency controller/screen latency is more than one frame. All I can say is that it passed these sections with full marks when used with a CRT telly. Also, unlike with some of my other wireless controllers, I found that the controller would re-sync to the dongle and allow gameplay to resume correctly if I walked away for long enough for the controller to go to sleep. I don't have a second XBox One/Series controller to test multiplayer atm (but I plan to if somebody else confirms that this works!). The only very slight downside I ran into is that I cannot map anything to the new "Share" button on the Series controller - hardly the end of the world, though! Great work - everything seems brilliant so far, and I will post again if I run into any troubles.

[MostroW]

before i forget to ask again, does it / or is it support(ing) multiple controllers using one usb device?

[sofakng]

Yup, it supports up to 4 controllers I believe.

[movisman]

I have carried out a bit of testing!

All great - works absolutely fine, no issues at all (I use the slim adapter so didn't test the alternative kernel).

Was able to map the controller exactly as expected - basically the driver works in exactly the same as it does on my older RetroPie instance. Pairing, reconnecting, auto power down, everything works with no issue. I paired two Xbox One 1708 controllers and two player worked just fine.

I also tested an Xbox Series X controller (1914) - this also works absolutely fine but does have this issue:
https://github.com/medusalix/xow/issues/144

I can replicate that every time.

In MiSTer if I leave the controller powered on but left alone it will momentarily disconnect and re-pair (just a few seconds) after approximately 30 seconds idle. If you are actually using the controller though it works and does not disconnect. You would only notice this if watching a cut-scene or you've paused the game, or you are sat on the UI or whatever. Auto power down still works though so it will still switch off properly if you leave it long enough.

This is likely a MS thing though because many users have reported similar issues already. And if it is related to xow in any way, it's not anything to do with the binary you compiled

So, all in all, very successful tests.

Cheers!

[sofakng]

Thanks for the testing and for the feedback.

There is a possible fix for the Series X/S controllers desync. I'll be compiling a new test version and let everybody know when it's ready. (probably on Monday morning)

[movisman]

Thank you! Is that possible fix related to this PR by any chance?

https://github.com/medusalix/xow/pull/142

It seems that a couple of comments on the PR suggest changing the driver didn't fix the issue, and it also suggests that the indicator light on the dongle no longer lights up when the connection is working (when using what is apparently the "newer" driver...later driver date but lower version number).

It is worth a try though, or was the possible fix you were thinking of a different one?

Happy to try another build and see what happens!

[sofakng]

Yep, that's the pull request I was going to implement

I'll let you know when it's ready. Thanks much!

[movisman]

Great thank you! I will give it a go as soon as it's ready. It'll be obvious if it helps or not as the issue is very easy to replicate - even though the intervals between each idle desync/resync can vary, ultimately it still happens on every boot and the first desync/resync is "usually" only after 30 seconds or so of idle time.

Thanks!

[Shaneus]

Seems to work great for me! Only problem I had was with the update script, where it was trying to detect the active user as 'MiSTer', but on mine for whatever reason it's 'root'. I just modified the script to remove those lines and it worked fine.

[sofakng]

I've updated the binary with a few changes:

* Latest git release of xow (includes fixes for issues with rumble)
* Newer driver for Xbox Adapter (re: Xbox Series X disconnects)
* xow_on and xow_pair scripts will download xow binary automatically (thanks Locutus73)

Locutus73 said the main MiSTer updater script will be updated today/tommorow to automatically download the xow scripts. However, you will still need to download/copy the newer linux kernel (zImage_dtb) if you have an older adapter until Sorgelig releases the new kernel.

Also, the xow_on and xow_pair scripts will only download the xow binary once. It will not update automatically so you can either remove it ( rm /media/fat/linux/xow) which will cause it to redownload or I will include another mechanism to update it (ie. xow_update.sh perhaps?)

I'm also looking into adding a simple wrapper to make sure the service restarts if it crashes.

Thanks!

[movisman]

Did a bit more testing with the latest release.

Unfortunately changing the driver has not solved the Xbox Series X disconnect/reconnect issue, but it has had the knock on effect of disabling the little LED on the dongle (which usually glows when paired/working).

This ties in with the comments on this PR which mention the LED and the PR unfortunately not resolving the problem:
https://github.com/medusalix/xow/pull/142

Post testing, I went back to the previous binary that uses the older dated driver, and the functionality of the little LED was restored.

With that in mind, I think it might be better to go back to the other driver, at least the LED functions on that? The disconnects unfortunately happen on both drivers. It's weird because the newer dated driver has an older version number (07/18/2018,1.0.45.5), and the older dated driver has a later version number (07/11/2017,1.0.46.1).

I reckon it's best to change it back to what xow currently uses (07/11/2017,1.0.46.1). The author of the driver also recently commented on another issue I posted an comment to: https://github.com/medusalix/xow/issues/144 - but ultimately thinks we'll just have to wait for MS to release a firmware update to solve these idle disconnect/reconnects.

They are slightly erratic and don't happen totally consistently - but they certainly are consistent enough to be able to replicate easily. However, the controller is still very usable, as it only happens when the controller is left idle for a short time and for me, it does reconnect by itself within a few seconds. There is a chance an idle disconnect/reconnect could catch you out after resuming from a cut-scene or something, but apart from that it's ok. No issues with the original Xbox One controller. Hopefully MS will release controller firmware soon to resolve this Series X related issue. I believe they are aware of it, there are some threads on reddit from Xbox BETA/insiders suggesting that they are still working on it. I guess other Windows/Xbox users are seeing similar behaviour so potentially fairly widespread.

Thanks!

[sofakng]

Thanks for the feedback. I've had a couple of reports of this not working so I'll revert the firmware change.

However, can you first test the attached binary and report back?

It's the same as the last release except it uses the older firmware. If it works OK then I'll upload this to git.

[movisman]

Thanks for the file - I replaced the xow file with the attached, but the LED still does not work. Tested a few times to be sure.

However, if I go back to the xow file from your initial release, the LED comes up immediately when the controller connects.

Another thing I noticed with the newer release regarding the script files, is when you run the xow_on script, it downloads some files via console and prints a CURL SSL cert related error on screen, before showing the script text and about starting the service (which it does with no issue). With the initial release, it did not throw anything related to CURL / certs and just shows the 'starting service' message. Not sure if this is known or will go away when rolled up into the proper update script, but worth mentioning as it doesn't happen on the first release.

Hope this helps.

Thanks!

[sofakng]

Hmmm, which Xbox Adapter are you using? The older (larger) one or the newer (slim) version? I'm using the older version and the LED is working OK with the version posted above.

Can anybody else verify or test the LED functionality with a newer and older adapter?

The only changes to xow between my initial binary this one are two commits (add support for Surface Book 2's built-in dongle and fixes for rumble). If the LED stopped working then perhaps one of these are causing a problem and we need to report an issue to upstream xow.

As for the CURL SSL messages, it's because MiSTer doesn't come with valid CA certificates installed. Therefore, the script first tries to use secure SSL to download xow and if it fails it uses insecure SSL. You can safely ignore those warnings, but if you want to improve security you can look into running the security_fixes.sh script. However, be careful because it has several security options that can disable SSH/SMB/FTP and lock you out of your MiSTer.

Also, as I'm writing this message it looks like upsteam xow was updated with two more fixes (correct GIP commands/docs and ignore packets from accessories). I'll compile another release and give it a try before uploading it.

[movisman]

Hi!

I'm using the newer (slim) version.

It still feels like it could be something with that binary you posted above - only reason I think that may be the case, is because I just uninstalled and reinstalled xow with the latest build on GitHub on my RetroPie x86 instance using the regular build instructions, and the LED works fine. So any new release doesn't appear to have broken it.

I just double checked the MiSTer and again, with the latest binary you provided above, the LED doesn't function. But if I go back to the first binary you released, it's fine. From what I read, the only time the LED doesn't function is if the driver pulled from MS is that one dated 07/18/2018 / 1.0.45.5. For whatever reason, that driver breaks the LED, but the 07/11/2017 / 1.0.46.1 driver (the one xow uses today) is fine.

Most odd!

Thanks for the tip about CURL SSL, I had read something about this before. I thought i'd mention it as it was another difference i'd noticed between the first release and all subsequent builds (first release showed no messages).

Thanks!

[sofakng]

Can you please give this binary a try?

Thanks!

[movisman]

I think I know what's going on here - in order to replace the 'xow' file over SFTP, I have to first disable the service by running the 'xow off' script.

Then I can replace the file. However, as 'xow' is now off and the services removed, I have to start it back up again by running the 'xow on' script. However - I had the newer script, and whatever files this downloads, it looks like it replaces the 'xow' file during the process, meaning my new file for testing gets overwritten by the download. The timestamp and file size changes on the 'xow' file.

Does that make sense? I'm assuming the script is downloading the files again from Github, which would be the release with the driver which breaks the LED.

So, to get around this, I used the 'xow_on' script from the very first release - which doesn't download anything, and no overwritten files.

Using that process to test, the LED works fine.

This means both the zip on the above post (Wed Jan 27, 2021 8:18 pm) AND the zip you posted on Tue Jan 26, 2021 2:26 am both work fine with the LED. Not sure what the differences are between the two xow files that you sent, but wanted to clarify both are ok.

Apologies for that - I didn't realise my testing xow file was being overwritten.

[sofakng]

OK - No problem. It was confusing because the initial xow_on.sh script didn't download the xow binary but the current one does.

I've gone ahead and committed the latest xow binary (same from .zip above). If you run the xow_on.sh script it will now download that version as well.

After a few days of testing if all goes well I'll flag this as version 1.0.

I'm still looking into methods to monitor/restart the process in case it crashes.

[movisman]

Yeah, i'm sorry about that. Hope you didn't spend too long troubleshooting. I had overlooked the fact that the newer script was downloading whatever version from GitHub, and in turn, overwriting the 'xow' file i'd manually put in place.

I've cleared out all the files and services and just put the scripts back in place (latest). Ran xow_on.sh and it grabbed the files, I restarted the MiSTer and tested the controller - LED works fine

So, looks good to me. What are the differences between the xow file you uploaded today and yesterday btw? Just the additional commits/updates?

I noticed this btw regarding that rumble patch:
https://github.com/medusalix/xow/issues/157

So I imagine there will be another update fairly shortly if this turns out to be a problem.

Thanks for all the help!

Good idea regarding monitoring/restarting the process in case it crashes. It was seemingly stable for me on my RetroPie instance, although it didn't get heavy use.

[sofakng]

No problem at all.

The latest version I've uploaded matches the latest version of xow from their git repository. It seems to contain some miscellaneous items such as correcting xbox property command documentation and ignoring packets from accessories. I don't think it would affect anything we are doing.

If the rumble fix turns out to have an issue I'll post a new binary as well with any fixes.

Thanks again for testing!

[movisman]

Perfect - sounds great! No problem with testing, happy to help where I can. So far things are looking positive and everything is working fine.

Hopefully Sorgelig updates the kernel soon so the larger dongle can function without a custom kernel needing to be installed.

Really great work on this.

Thanks!

[Shrapnl]

Hi all,

I'm new here, just built my first MiSTer over the last few days but have been keeping an eye this project since first learning about it in Smokemonster's videos a couple of years ago in his marathon video series on the various cores at the time.

I have had one of the "fat" adapters for many years and have today received one of the newer "slim" ones. Here are my findings:

*Current release via update_all scripts
MiSTer v210109, OS v200908
-Fat - no light, can't pair
-Slim - light, can pair, works fine

*Patched linux via zImage_dtb in the repository for xow
MiSTer v210109, OS v200908 (was a little surprised, assumed there would be a date or build difference)
-Fat - light, can pair, works fine
-Slim - light, can pair, works fine

For clarity, so far I have only used an Elite Series 1 so far for testing. Both adapters and the controller were plugged into a Windows 10 system and had any updates applied via the Xbox Accessories app.

I do have a few other Xbox controllers if needed for testing at any point.

-Shrapnl

[sofakng]

@Shrapnl, thanks for testing!

Your results look like what is expected.

The Linux kernel (zImage_dtb) is different from the MiSTer version and the menu version. I'm not sure the version appears anywhere but my custom build might not show a different version regardless.

The patched linux kernel adds support for the "fat" Xbox Adapter (as your results have shown). Once Sorgelig pushes a new release of the kernel you won't need to download the special version any longer.

[JonnyTenebrous]

Quick question. Does this XoW driver now come as standard with MiSTer Main, or is it still in testing? I'm considering a backup/reformat/refresh of my MiSTer for general maintenance, and figured I'd wait until XoW is ready for prime time (even though I realise it can be installed manually, having already done so in my current install). Thanks!

[mario64]

With today's update is this supported by default now?