Adding support for the Xbox Elite Controller 2 about missioncontrol HOT 151 CLOSED

@kylefmohr yeah that's perfect. I'll try to finish writing some tools to try this out after I'm done with work today.

from missioncontrol.

Hey, sorry for the lack of updates. I've written a python script to dump the database from L4T and have some basic functionality to import it back into HOS, but it doesn't seem to work in all cases for some reason. In particular I couldn't get my regular Xbox One controller to be recognised. I need to do more research. I will try to dedicate a bit more time to look into it this week. It's hard when I don't own the controller

You could check for me if any of the changes I made in 0.3.0 have made any difference to the pairing situation if you like. Thanks for your support :)

from missioncontrol.

I just know it's gonna work, because I bought an 8bitdo like 12 hours ago lol

I will test this afternoon and let you know shortly

from missioncontrol.

So recently yellows8 added this branch to Atmosphere which can log the low level uart communication between the Bluetooth driver and the hardware. I made a build of it if someone wants to install it and make a log of their attempts to pair the controller. This should yield me something very similar to the android btsnoop logs somebody posted above to compare.

atmosphere-0.18.0-uart_mitm-1eb4c992-dirty.zip

Install the above build as you would normally install Atmosphere and add the line enable_uart_mitm = u8!0x1 under the section [atmosphere] in /atmosphere/config/system_settings.ini then reboot the console to enable the logging. The logs will be created in atmosphere/uart_logs

from missioncontrol.

Your settings file did the trick, here are the logs:
uart_logs.zip

from missioncontrol.

I didn't realise there was a Bluetooth version of the Elite Controller. It's probably just a matter of whitelisting the hardware ID.

If you have one could you attempt to pair it via the Controllers->Change Grip/Order screen, then use btdb.nro provided with the release to dump the Bluetooth database and post a screenshot here.

from missioncontrol.

I've got the Elite Controller 2, and we can't pair him, so we can't get any enter on the Bluetooth database

from missioncontrol.

@shyiro even though the controller might not appear to connect to the switch, it should be possible to complete the pairing process with the console and get it stored in the database. It will only show up as a connected controller if a handler gets installed for it, which requires a match against the hardware ID to determine the controller type.

from missioncontrol.

ok i see, but i've try a lot of time to pairing him, but the controller keep blink and no enter in the database for him. i don't know if it's linked, but, when i try to pairing him, and go to btdb.nro for see if he is here, sometime i get a crash of atmosphere.

from missioncontrol.

MissionControl-0.1.0-xbox-one-elite-2.zip
I've whitelisted a hardware id I found online that appears to be the Elite Controller v2. See if this build makes any difference for you. Also might be worth making sure your controller firmware is up to date

from missioncontrol.

doesn't work, Atmosphere keep crashing a few seconds after i try to pair him

from missioncontrol.

Hmm, that's odd. Can you post the fatal report here so that I can see what's crashing and where?

from missioncontrol.

the crash come randomly after i try to pair him, if i stay in the controller menu, or in the hbmenu, anywhere i go, it's crashed a few seconds after try to pair.

from missioncontrol.

Thanks. I'll check it out when I have some time.

For future reference, it's much better if you post the report log file that gets written to your SD card under atmosphere\fatal_reports. That way I can use automated tools to inspect it rather than having to key in the addresses manually ;)

from missioncontrol.

oh sorry, i didn't know that ^^

01598542087_010000000000002a.log

from missioncontrol.

MissionControl-0.1.0-xbox-one-elite-2.zip
I've whitelisted a hardware id I found online that appears to be the Elite Controller v2. See if this build makes any difference for you. Also might be worth making sure your controller firmware is up to date

This modification was very useful.
Friend of mine only managed to connect his control with this version, and it is not an elite control.
It is a normal Xbox One controller.
Maybe it's a slightly different version.

from missioncontrol.

@victorgneves that's strange, is it an official Microsoft controller? As far as I can remember, the only change I made for this build was adding the ID {0x045e, 0x0b00} to the whitelist for Xbox One controllers. Can your friend dump their Bluetooth database with btdb.nro and post it here?

from missioncontrol.

@shyiro try this build with logging enabled, and post the resulting btdrv-mitm.log from your SD root here. Note that the log gets wiped on console boot, so if your switch crashes you will need to either pull the SD out and read it in a computer, or mount it from hekate to read it before booting.

MissionControl-0.1.0-debug-logging.zip

from missioncontrol.

I've got the same controller, and get (seemingly) the same crash (I go to change grip/order, try to pair my controller, and when I try to return to the main menu, it crashes).
Here's my atmosphere fatal log
01549653030_010000000000002a.log
And here's my btdrv-mitm.log (from the last build you sent)
btdrv-mitm.log

from missioncontrol.

Thanks @PabloPerezRodriguez . Unfortunately, nothing too interesting in those logs. It looks like it might just try to pair twice and then crash. Could you try with this new build with more verbose logging of the pairing process?

MissionControl-0.1.0-debug-logging2.zip

from missioncontrol.

First thank you for the great work, second I join the request to add the elite v2 to the supported list please

from missioncontrol.

@elad0elad you could try running the build I've posted above and post your log. I can't add support if I can't figure out why it won't connect. I don't own this controller myself.

from missioncontrol.

Sorry for the delay, my SD Card got corrupted and I was trying to recover my data (didnt work).

I tried again with the new build. These are the logs.
btdrv-mitm.log
01550003809_010000000000002a.log
I also noticed Atmosphere creates crashdumps, not sure if you want that, I'm not uploading it here because I don't know if it contains console specific info.

from missioncontrol.

@elad0elad you could try running the build I've posted above and post your log. I can't add support if I can't figure out why it won't connect. I don't own this controller myself.

I've been trying this and still don't work friend, there is any thing I can do to help the progress?

from missioncontrol.

Sorry guys, I'm busy preparing some other things for the next release at the moment. I want to knock you up a homebrew application to do the bluetooth pairing myself and see if we can at least avoid the crash for further debugging. Give me a day or two.

@PabloPerezRodriguez thanks for the logs. Looks like you're getting authentication failure status events before the crash. Not exactly sure what could cause this. Reading around a bit it kind of seems a bit like the QC on the elite controller is worse than the standard ones that come with the xbox. I don't think you've mentioned whether your controller is on the latest firmware or not? Make sure it's up to date as it sounds like there have been improvements to the bluetooth function over time.

You can upload the Atmosphere crashdumps too if you want. At the moment I don't really need them as the stack trace is enough, but they might prove useful if I end up having to dive deeper into the disassembly to figure out what's going wrong.

from missioncontrol.

It is on the latest firmware. And don't worry about time, I can wait!

from missioncontrol.

There is an option to add the controller by enter the Mac address manually?

from missioncontrol.

@elad0elad no, the pairing process has to complete with the controller to exchange link keys with the console.

from missioncontrol.

I can't even get my Elite 2 to connect at all :(

from missioncontrol.

i tried so may times to pair my elite 2 controller with the console but no luck. The controller is blinking like its searching to pair but no luck.Also i try the btdb.nro program but it says no paired bluetooth devises

from missioncontrol.

Hey guys, sorry it's taken so long. Other things have got in the way.

Here's a little homebrew app I made to reimplement the pairing process. It's not perfect and may have some bugs, but hopefully it won't crash if you try to pair the elite controller. See if you can manage to get it to do anything interesting. A successful pairing will show the device info in green. It creates a log at sdmc://bluetooth_pairing.log that you can upload here for me to take a look at.

bluetooth_pair.zip

from missioncontrol.

bluetooth_pairing.log

Here's a log - I left it running for a bit just in case some logs were different than others. Thanks for doing all this man!

from missioncontrol.

@Dallas-J thanks for the log. I assume this didn't crash on you then by the looks of that log? I probably should have timestamped it.

Looks as though it's continually failing the authentication step. Here are a few versions I built tweaking the parameters to the authentication response. I don't see why this controller should be different to any other, but I guess it can't hurt to try. Let me know if you find success with any of these.

bluetooth_pair_A.zip
bluetooth_pair_B.zip
bluetooth_pair_C.zip
bluetooth_pair_D.zip

from missioncontrol.

bluetooth_pairing.log
here's my log,
allready try all 4 version and the one thet you upload earlier, nothing change

from missioncontrol.

@elad0elad damn, this controller really doesn't want to work.

Are any of you guys able to pair this controller on linux and share the pairing info? This might help understand if there's anything different to a regular Xbox One controller. I'm also thinking a workaround might be to pair the controller under switch linux and inject the info into the database under HOS.

from missioncontrol.

bluetoothctl.log

I'm uploading this from switchroot - is this what you're looking for? I had just disconnected the controller so it failed to pair at first.

from missioncontrol.

Is this what you're looking for @ndeadly ? Let me know if I can provide additional information

hcitool info.log

from missioncontrol.

@Dallas-J , @kylefmohr sorry if there was confusion from me asking for logs earlier. That was mostly for diagnosing what was going on under HOS. What I'm actually after from linux is the equivalent to what would get stored in the HOS bluetooth database. I don't know if it's the same across most distros, but under ubuntu this can be found at /var/lib/bluetooth/<host_address>/<client_address>/info. My hope is that I might be able to find all the necessary info in here to translate to the switch database format and inject it into the database under HOS. I'd still like to figure out why the pairing fails on HOS, but this could act as a workaround for you guys in the meantime. The ability to do this would also be useful for people running switch linux or emuMMC who want to synchronise their pairing databases.

from missioncontrol.

Like this?

root@kyle:/var/lib/bluetooth/98:B6:E9:AA:35:57/98:7A:14:5B:35:BF# cat info
[General]
Name=Xbox Elite Wireless Controller
Class=0x000508
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false

[DeviceID]
Source=2
Vendor=1118
Product=2821
Version=1032

[LinkKey]
Key=16E555BC220168E6E8C85E9C6D55A716
Type=4
PINLength=0

This was taken from L4T Ubuntu on my Switch.

from missioncontrol.

Hi @ndeadly, just wanted to see if there was any additional information I could provide to assist with adding this controller to MissionControl.

Thanks for all of your hard work so far. I’d be happy to send another donation once this is added 🙂

from missioncontrol.

No worries! I will try 0.3.0 tonight and let you know if there's any noticeable change. I'd be happy to test the L4T and HOS script for you once it's ready, if that would help.

from missioncontrol.

No change on 0.3.0 unfortunately, still not detected.

from missioncontrol.

@kylefmohr yeah not all that surprising. Just wishful thinking on my part that the thread priority bug I solved in 0.3.0 may have been to blame.

from missioncontrol.

Hey I was wondering if you made any progress on the elite controller. I'm guessing the controller does some strange stuff when paring because I also have the mayflash switch Bluetooth adapter and I think its got a unique pairing process as it took around 15-30 seconds to pair. Also here a quote from their pairing guide for the elite controller

• It may take a longer time to connect your Xbox Elite 2 and Magic-S adapter. And the connection may be disconnected shortly (The lights on the controller and the adapter flash) and then connect again during the Bluetooth pairing process. Please wait patiently until the LED indicators on the controller and the adapter stop flashing.

I hope this helps

from missioncontrol.

Hey I was wondering if you made any progress on the elite controller. I'm guessing the controller does some strange stuff when paring because I also have the mayflash switch Bluetooth adapter and I think its got a unique pairing process as it took around 15-30 seconds to pair. Also here a quote from their pairing guide for the elite controller

* It may take a longer time to connect your Xbox Elite 2 and Magic-S adapter. And the connection may be disconnected shortly (The lights on the controller and the adapter flash) and then connect again during the Bluetooth pairing process. Please wait patiently until  the LED indicators on the controller and the adapter stop flashing.

I hope this helps

To add to this line of thinking, I use switch up adapter for it's bluetooth capabilities and it pairs without delay with xbox elite controller 2 to the adapter, and then a couple second delay before the controller led stops flashing.

from missioncontrol.

Good day! Is there any progress in pairing Elite v2 Controller? If you need any assistance I could help by launching some tools or scripts and providing you it's output.

from missioncontrol.

Hey, sorry, no major updates. I've been sick the past week or so, so not a lot of dev work being done. I'm slowly working towards having a gui application that will allow exporting and importing the controller database amongst other things. It might be possible to use this to restore the pairing info from l4t, but it's also possible that controller is being rejected by the console during connection for some other reason. It might require patching of the bluetooth service. This is a difficult problem to solve without access to the controller to be able to live debug the connection process.

from missioncontrol.

Is this something we could crowdfund for you? It's a very nice controller, albeit pricey. I'm in for $10, anybody else? And is this something you're interested in @ndeadly ?

Failing that, I have a fair amount of Bluetooth receivers, access to any VM you might need, and at least adequate knowledge of how all these things work (though I know almost nothing about the nitty gritty of Bluetooth connections). Would you want to remote into a VM I host and you could instruct me to put the controller in pairing/move files to the Switch as needed? Just a thought, I'm willing to help however I can.

from missioncontrol.

@kylefmohr if people wanted to crowdfund the controller for me so that I can dig deeper I'd happily accept. It needs to be made clear though that this will not necessarily guarantee a solution. The last thing I want is people feeling that I owe them any results because of it.

While I appreciate the offer of remote access, I don't think it's really practical. A lot of this work can require staring at decompiler output for hours and messing around in gdb, but also rapid testing of new ideas and iterating upon them. The delay/overhead from having to communicate every little thing, plus needing you there the whole time on standby would quickly frustrate us both.

from missioncontrol.

@kylefmohr if people wanted to crowdfund the controller for me so that I can dig deeper I'd happily accept. It needs to be made clear though that this will not necessarily guarantee a solution

Yes, absolutely. Something I was taking for granted, but it's definitely a good idea to mention. Chipping in != guaranteed support for the controller (or any guarantees, really)

A lot of this work can require staring at decompiler output for hours and messing around in gdb, but also rapid testing of new ideas and iterating upon them.

That makes sense.

from missioncontrol.

plus needing you there the whole time on standby would quickly frustrate us both.

I am totally agree, but if you will need to test something or make some dump don't hesitate to contact me. I can't afford to crowdfund something with money, but I could sacrifice some of my free time

from missioncontrol.

Just thought of something else to try...

If someone with an Android phone could try and connect the controller to their phone with the HCI snoop log enabled that might provide us with some additional info. The Android Bluetooth stack is similar to the one used by the Switch.

from missioncontrol.

here is mine
btsnoop_hci.log

from missioncontrol.

@ndeadly This is a bit unorthodox, but on the off chance we live in the same area I have the xbox elite 1, 2, and razer wolverine ultimate controller (as well as a bottle of 99% isopropyl alcohol for your safety) that I am comfortable lending for science.

from missioncontrol.

@kintsugi haha I admire your enthusiasm. If you happen to live in Southern Germany we can talk ;)

from missioncontrol.

@kintsugi haha I admire your enthusiasm. If you happen to live in Southern Germany we can talk ;)

Haha thanks! I live in San Francisco, CA, so unfortunately it won't work out 😪

Here's an idea: I have a desktop computer I use for kvm/libvirt, I could spin up a linux/windows/whatever image for you, passthrough a bluetooth adapter and connect the controller. Then I could follow your instructions to send input/press buttons. What do you think?

from missioncontrol.

Anybody want to update their controller to the latest firmware and give this build a try? It's been brought to my attention there may have been some firmware bugfixes recently, and I was also sending an unnecessary command to the controller. Don't want to get anyone's hopes up, but there's a small chance one of those things could have been the cause of problems for the Elite v2.

MissionControl-0.4.1-no-xbox-init.zip

from missioncontrol.

I don't like to drop into a non-technical discussion but this one may be important. All non-programmers: Please ignore. :-)

Anybody want to update their controller to the latest firmware and give this build a try?

@ndeadly The XBE2 reports are larger (and in the older buggy firmware much larger) than the older controllers reports. Does the code handle this gracefully? What happens if the packet is shorter than what's expected (as in report->data is shorter than XboxOneReportData)? Would this end in an out of bounds access and crash MC?

For xpadneo, we've made these captures: https://github.com/atar-axis/xpadneo/blob/master/docs/descriptors/xbe2_unknown.md

It could help you finish support for this controller. Also, it seems we need to enable Bluetooth privacy extensions for a reliable connection. IDK if this is something MC needs to bother with, or if it can change BT behavior of the console.

I think it may be worth considering the report size to tell the protocol variants apart although the first few bytes are always the same purpose. It starts to change with the buttons (XB1S controllers may either report 10, 11 or 16 buttons, the 16-button mode uses a sparse bitmap and the report is one byte longer, the 10-button mode reports the guide button in report 0x02). XBE2 adds some more bytes (older firmware has a duplicate set of bytes), the additional bytes have information about trigger mode, paddels and profile switcher. The new (not yet supported) XBXS controller reports 12 buttons, and shifts some button bits compared to the older models.

from missioncontrol.

You can always drop in if you're gonna provide useful information like that!

@ndeadly unfortunately no luck on the build you just posted, the controller simply doesn't show up. To recap, I:

• Ensured XBE2 had the latest firmware
• Overwrote previous MissionControl release with the no-xbox-init version
• Rebooted, ensured the sysmodule was running, rebooted again
• Also power cycled the XBE2

Still nothing in the change grip/order menu. My switch is running FW 11.0.1 + Atmosphere version 0.16.2

Just posting as much info as I can in case I'm forgetting something stupid.

from missioncontrol.

@ndeadly Would it help to capture a btmon or wireshark dump in Linux for the controller connecting/pairing? Then maybe pressing each button and axis along with a video of showing all the controller functions?

from missioncontrol.

BTW: The long connection handshake is gone in Linux since the kernel supports Bluetooth privacy extensions properly and this feature has been enabled in the bluez configuration file. For the Switch console, this may however not apply or work completely different (different Bluetooth stack).

from missioncontrol.

@kakra the console stores hid reports to the following structure, so unless the incoming report size exceeds 700 bytes it shouldn't be an issue. I reinterpret cast this structure to the appropriate controller report definition. Worst case is the controls are mapped incorrectly.

typedef struct {
    u16 size; 
    u8 data[0x2BC]; 
} BtdrvHidReport;

We don't even appear to be making it to the point the controller starts sending reports though. I believe it's failing at some point during the connection/pairing process. I can't really debug this however as I can't log anything going on inside the driver. I would need the controller to either remote debug the driver from my PC or capture the packets via some other means.

Also, it seems we need to enable Bluetooth privacy extensions for a reliable connection. IDK if this is something MC needs to bother with, or if it can change BT behavior of the console.

Not sure on that one either. I don't have a lot of influence over the console Bluetooth other than a few SSP pairing settings. Anything else would likely need to be patched in. Do the privacy extensions apply for all Xbox One controllers or just the Elite? I don't have any connection issues with the regular one on the Switch.

@ndeadly Would it help to capture a btmon or wireshark dump in Linux for the controller connecting/pairing? Then maybe pressing each button and axis along with a video of showing all the controller functions?

Not sure, couldn't hurt to take a look. I think I already had someone grab me an hci snoop log from android earlier in this thread, but I don't recall seeing anything particularly interesting. My main interest is what happens during connection or authentication that might be different from the regular Xbox One controller.

from missioncontrol.

You can always drop in if you're gonna provide useful information like that!

@ndeadly unfortunately no luck on the build you just posted, the controller simply doesn't show up. To recap, I:

• Ensured XBE2 had the latest firmware
• Overwrote previous MissionControl release with the no-xbox-init version
• Rebooted, ensured the sysmodule was running, rebooted again
• Also power cycled the XBE2

Still nothing in the change grip/order menu. My switch is running FW 11.0.1 + Atmosphere version 0.16.2

Just posting as much info as I can in case I'm forgetting something stupid.

@kylefmohr not particularly surprising, but thanks for trying. Does the console crash at all anymore?

from missioncontrol.

I personally have never experienced crashes due to MissionControl

from missioncontrol.

Not sure on that one either. I don't have a lot of influence over the console Bluetooth other than a few SSP pairing settings. Anything else would likely need to be patched in. Do the privacy extensions apply for all Xbox One controllers or just the Elite? I don't have any connection issues with the regular one on the Switch.

I'm not sure if it affected the older models as I was already able to pair them without problems in Linux. But it changed connection behavior of the XBE2 very visibly: It's more or less immediate now compared to a 20 second long "frozen phase" before. In a long gaming session, all models stay connected much more reliable, tho that may be a placebo effect or purely subjective: I did turn off rumble around the same time which makes all controller models much more stable in Bluetooth mode anyways.

Multiple users of xpadneo reported that turning on privacy extensions fixed most problems for them, with XBE2 and especially the new XBXS model.

Compared to Android (which seems to use a Bluetooth stack very similar to the Switch console): There the controllers seemed to connect without problems since the beginning. But I don't remember if I tried the XBE2 controller. I probably did try, and if I did, I would remember if it had connection issues. So let's assume it connected without problems on XBE2.

I'll try to create a Bluetooth dump of pairing/authentication in the weekend and send it to you. Any suggestions which Linux capturing tool I should use for best results?

from missioncontrol.

BTW: All the PID/VIDs of the models are here: https://github.com/atar-axis/xpadneo/blob/master/hid-xpadneo/etc-modprobe.d/xpadneo.conf

The XBE2 controller is 0x0B05, XBXS is 0x0B13.

This is for Bluetooth mode. The USB modes of the controller actually use different IDs which you could see here:
https://github.com/atar-axis/xpadneo/blob/master/hid-xpadneo/src/hid-xpadneo.c#L864 (and following lines)

The Bluetooth IDs are also in the code here:
https://github.com/atar-axis/xpadneo/blob/master/hid-xpadneo/src/hid-xpadneo.c#L1160

Once connected/authenticated in Bluetooth, there should actually really be no difference in handling the controller in the code (except for some differences in the HID reports). So if XBE2 does not connect, it's probably somewhere in the Bluetooth handshake phase.

from missioncontrol.

Multiple users of xpadneo reported that turning on privacy extensions fixed most problems for them, with XBE2 and especially the new XBXS model.

Have you got any further info on these privacy extensions? I might try to take a look into it.

Compared to Android (which seems to use a Bluetooth stack very similar to the Switch console): There the controllers seemed to connect without problems since the beginning. But I don't remember if I tried the XBE2 controller. I probably did try, and if I did, I would remember if it had connection issues. So let's assume it connected without problems on XBE2.

Yes, the switch Bluetooth stack is very similar, it's why I thought the Android hci log might have been useful. I don't think I've heard of anyone having issues on Android either.

I'll try to create a Bluetooth dump of pairing/authentication in the weekend and send it to you. Any suggestions which Linux capturing tool I should use for best results?

Thanks, that would be helpful. I'm not super familiar with which tools are available for this purpose on linux, I thought you might have a better idea. I haven't needed to see the low level packets before so I've been able to just log from MC

from missioncontrol.

Once connected/authenticated in Bluetooth, there should actually really be no difference in handling the controller in the code (except for some differences in the HID reports). So if XBE2 does not connect, it's probably somewhere in the Bluetooth handshake phase

@kakra I've already got the controller IDs in place. I expect everything to just work (bar correct control mappings) as soon as I've got this connection issue figured out. Yeah I'm fairly certain it's the handshake failing somehow. Not sure why it should be any different to the regular XB1 controller though.

from missioncontrol.

Have you got any further info on these privacy extensions? I might try to take a look into it.

Well, there's this section in the Bluez main.conf which needs to be set to device:

# Default privacy setting.
# Enables use of private address.
# Possible values: "off", "device", "network"
# "network" option not supported currently
# Defaults to "off"
# Privacy = off
Privacy = device

Then maybe look at commits to the Linux source code in the directory net/bluetooth/ which have "privacy" in their commit logs.

from missioncontrol.

BTW: That Bluez setting really needs a current kernel. Back when I tried in 5.4, it made no difference. In 5.10 it seems to do its job. I think proper support appeared somewhere around 5.8 or 5.9, so you may look at commits in {drivers,net}/bluetooth/ if you find anything interesting which may raise an eyebrow or two for you. ;-)

I'm pretty much lost when it comes to understanding how the Bluetooth protocol works. Information about that is either sparse or cryptic. :-)

from missioncontrol.

There may be some useful insights here: atar-axis/xpadneo#198

from missioncontrol.

I've already got the controller IDs in place.

Yeah but 0x0B00 probably doesn't belong to that list - it's a USB mode ID, not used in Bluetooth mode by the XBE2 controller.

from missioncontrol.

Well, there's this section in the Bluez main.conf which needs to be set to device:

Thanks, I'll see if I can figure out what this corresponds to in the Bluetooth spec.

I'm pretty much lost when it comes to understanding how the Bluetooth protocol works. Information about that is either sparse or cryptic. :-)

Yeah I know what you mean. My understanding of classic Bluetooth is patchy at best. Most of it has come from reading android source. I've been trying to read up on LE in order to implement support for MC but it's spread across so many different documents and difficult to make sense of. Best info I've found has come from nordic semiconductor rather than the spec itself.

Yeah but 0x0B00 probably doesn't belong to that list - it's a USB mode ID, not used in Bluetooth mode by the XBE2 controller.

Yeah I was just covering all bases. A lot of sources online don't make it obvious which interface the IDs correspond to. I'll likely add USB support in the future anyway

from missioncontrol.

I'll likely add USB support in the future anyway

In that case the controllers no longer speak HID but Microsofts proprietary GIP. For the latter one, you're going to need the init sequence with op-code 0x05 again. GIP is similar in structure but needs sequence numbers, init sequences, and op-codes are different. I'm also planning on implementing GIP support in xpadneo, so we eventually could join forces.

from missioncontrol.

I'm assuming I should have MissionControl installed while I collect these logs, is that correct?

from missioncontrol.

@kylefmohr yeah, without it running the switch won't even attempt to pair with the controller. You might also want to try with this build I made a couple of days ago. I discovered a vendor command the switch sends on connection was causing some controllers to be disconnected by the console. Might be worth ruling out the possibility of that messing with anything

from missioncontrol.

Hmm, oddly I believe that system_settings.ini addition enable_uart_mitm = u8!0x1 is causing Atmosphere to panic upon boot. It's blaming Title ID 010041544D530000, which I do not have in my /atmosphere/contents folder. Seems to be a well-documented issue with various causes, but none of the fixes I've seen worked for me. Before I started working on this, I wasn't using a system_settings.ini file, I installed your linked version of Atmosphere, and created the system_settings.ini file with just the single line in it. It panicked, so I deleted the Atmosphere and sept folder, and re-added them to my SD from your zip file. Same panic once again. I then downloaded and installed the latest release of Atmosphere from the official Github release, installed the system_settings.ini file and that new missioncontrol build, same panic. Finally, I deleted the system_settings.ini file and it booted just fine.

Let me know if there's something else I should try.

tl;dr couldn't collect logs yet

from missioncontrol.

@kylefmohr that title ID is for the ams_mitm module, which hosts mitms for various services. The cause of the crash could be any number of things so I wouldn't waste too much time trying random fixes. You may have a malformed system_settings.ini if you created it yourself. Try the one I'm using, I created it from the template.

system_settings.zip

from missioncontrol.

Thanks for the insight - I will try yours, but also, I was just typing a response that I just tried a different version of the system_settings.ini file, I copied it from the config_templates folder, and added the uart line to the end of it. I could have sworn I tried that earlier. I'll let you know if I am successful with getting these logs

from missioncontrol.

Cool, thanks. Did you do this with other wireless controllers connected? There seems to be a bunch of noise from another device in the log

from missioncontrol.

Oh yeah, that was from my Switch Pro controller. One sec, I'll redo it!

from missioncontrol.

uart_logs.zip

Hopefully this is better, I turned off bluetooth on all nearby devices

from missioncontrol.

Sorry for the lack of updates guys. @kylefmohr I wasn't really able to spot anything in those uart logs other than what looks like the console disconnecting the controller before authentication completes (which we already knew)

Has anyone attempted to pair the elite v2 on 12.0.1? Nintendo rewrote a bunch of the bluetooth code, so it's possible that their changes allow the controller to complete pairing.

from missioncontrol.

Sorry for the lack of updates guys. @kylefmohr I wasn't really able to spot anything in those uart logs other than what looks like the console disconnecting the controller before authentication completes (which we already knew)

Has anyone attempted to pair the elite v2 on 12.0.1? Nintendo rewrote a bunch of the bluetooth code, so it's possible that their changes allow the controller to complete pairing.

Fun fact, If I load MissionControl-0.4.1-settsi-mitm.zip with firmware v12.0.1 the switch refuses to boot! :D, In order to get it running again I have to remove the contents folder

Using the latest atmosphere stable, it gets to the white atmosphere logo then it just boots to a black screen

from missioncontrol.

@DatenThielt this is to be expected. Any builds prior to the 0.5.0 pre-release are compiled with an outdated libstratosphere and will not work with atmosphere 0.19.0+. The changes in that build have since been merged anyway, so there is no reason to use it over the latest release.

from missioncontrol.

That would explain that! did not see the pre-release, I will try with 0.5.0 now!

from missioncontrol.

So switch loaded fine, Went to Controllers and Sensors, Change Controller/Grip Order. Then entered paired mode on the Elite series 2 controller, nothing happened on the switch at all and the controller is still in pairing mode. Is there anything you need from me

from missioncontrol.

You could try it a few more times just to be sure, and maybe check if your controller is on the latest firmware, but that's about all I can think of. I'm not overly hopeful that anything will have changed with regards to this controller working though. Just thought it could be worth a shot since the 12.0.0 firmware update made some reasonably significant changes to the code.

from missioncontrol.

Yup thats the plan, It was a new controller today so of course it has some firmware updates, Doing those as we speak, I will try it again a few more times after and see if the switch does anything different and report back!

from missioncontrol.

No Go unfortunate, I thought maybe because the controller had no name either it might not work so I gave it a name from the xbox app but still not anything happening on the switch side unfortunately, I'm quite technical and willing to put in any effort to help get this working if needed! (I cant buy you a controller I'm afraid!)

from missioncontrol.

That's a shame. As far as I can tell from the uart logs posted earlier, the controller is actually being authenticated with the console, but something is happening afterwards that causes it to be disconnected before pairing is considered to be complete. I've been told this controller sends a massive hid report descriptor, so it could be something like this triggering it. I think what really needs to happen is debugging the bluetooth process on-console using something like twili as you try to pair the controller, to try to determine where it actually fails. If this sounds like something you'd be capable of, then I'd be quite happy for you to try it. Unfortunately I can't offer you too much in the way of guidance though.

from missioncontrol.

So I did attempt Twili, got it installed, cert installed, drivers installed. however it seems its not compatible with the latest version of Atmosphere as it crashes atmosphere on startup, :/

from missioncontrol.

Yeah I'm not sure if it's been updated or not. Haven't used it in a while. It may be better to wait for the debugging tools that sciresm has been working on. These will be based on Nintendo's own tools so should be a lot easier to work with and kept up to date with atmosphere

from missioncontrol.

So ignoring Twili, Is there any way to debug/breakpoint the code whilst its running on the switch? Or to get it to pop up any kind of debug messaging other than verbose? Happy to try anything to help :D

from missioncontrol.

I've been told this controller sends a massive hid report descriptor, so it could be something like this triggering it.

The descriptor becomes much smaller after updating the firmware of the controller using the Xbox Accessories app. Also, I've seen it simply disconnect if some Bluetooth packets are sent in some unexpected order but at least in Linux, this disconnect was host-initiated: It would first authenticate successfully, then become disconnected with "authentication failed" which is somewhat strange, it's like the controller is in some quantum fluctuation and when you look at it: boom!

from missioncontrol.

@kakra this sounds a lot like what we're seeing here actually. How was this resolved under Linux? Or do you mean to say it's intermittent and still occurs?

from missioncontrol.

So ignoring Twili, Is there any way to debug/breakpoint the code whilst its running on the switch? Or to get it to pop up any kind of debug messaging other than verbose? Happy to try anything to help :D

I don't know of any other tools that can be used to debug code running on the switch. As I said earlier, SciresM has been working on a reimplementation of some of Nintendo's own debugging tools. This should end up being a superior alternative to Twili, but currently there is no ETA as to when that might be released.

from missioncontrol.

@kakra this sounds a lot like what we're seeing here actually. How was this resolved under Linux? Or do you mean to say it's intermittent and still occurs?

Still intermittently occurs. Sometimes it takes 10 tries in a row to successfully connect it. Especially the XBE2 controller seems to be sensitive to other Bluetooth devices around, especially while a discovery/scan is running.

from missioncontrol.

So ignoring Twili, Is there any way to debug/breakpoint the code whilst its running on the switch? Or to get it to pop up any kind of debug messaging other than verbose? Happy to try anything to help :D

As an update on this - twili has now been updated to work with 12.x.x, but I have also just had luck debugging with gdb using sys-gdbstub to dig into the running bluetooth process in order to understand and make patches to get Wii controllers pairing again on 12.x.x. It seems as though a similar thing was happening there - controller pairs successfully according to hci logs but is disconnected before it gets added to the pairing database because something else fails directly afterwards. I'd love to be able to look into this too if I had access to the controller, while it's all fresh in my mind. If you'd like any help setting it up and investigating for yourself I'd be happy to help.

from missioncontrol.

i would love to have help, ive been wanting to pair my elite 2 to my switch for a while now

from missioncontrol.