Add support for 8Bitdo SN30Pro and SN30Pro+ on Xinput mode. about missioncontrol HOT 34 CLOSED

So I think I finally understand the problem here. Earlier this week myself and @Banz99 were investigating why we see a similar behaviour to what you described with Xbox One controllers under mission control. We discovered that although the switch data format allocates 12 bits for both X and Y stick axis, an official controller doesn't actually use the full range of the 12 bits. The actual limits are fuzzy and vary from controller to controller. The normalised range for my pro controller is only about ±0.75. The values are even lower on my joycons (0.5-0.6ish). With official controllers I think these range values are read from the controller's SPI flash and the input gets adjusted accordingly. For other controllers it seems that a value of around ±0.7 is assumed by default when we don't pass along valid range data. Since mission control assumed the full range of the 12-bits was used (ie a range of ±1.0) and scaled the inputs accordingly, the outer 30% or so of stick travel falls outside of the range the console expects and ends up being clamped to the maximum. It turns out this actually affects every single controller supported by mission control to some degree! By introducing an additional scaling factor to bring the mapped values back down to around ±0.7 we were able to fix the issue universally (although I think figuring out how to pass the exact range we're using to the console would be the ultimate solution).

I think you'll probably find the 8bitdos are doing the same thing - taking the 16-bit format used by XInput mode and scaling it down to the full range of the 12-bit format used in switch mode, while returning invalid analog stick parameters. 8bitdo would need to implement a similar fix in their controller firmware to that I described above in order for Switch mode to work correctly, but we can probably fix this under XInput mode with mission control now!

from missioncontrol.

You might be able to rebind the controller in the Switch settings

from missioncontrol.

I didn't even try it because the problem is not that bottoms are just binded wrongly, the problem is that half of the bottoms are outright not working.

from missioncontrol.

I'm guessing that the controller must look like a real Switch Pro Controller to MissionControl, and is assigned a passthrough handler, but then starts sending data in the wrong format in Xinput mode. Could you clear your pairings, repair the 8bitdo, and then send me a dump of the database? I'm curious whether there's any way to differentiate it from a real Switch controller. If it can't be uniquely identified it will be hard to handle the controls correctly without some kind of manual override option.

from missioncontrol.

This is the dump for the SN30 Pro+

I'm not with the SN30 Pro with me right now, but I think tomorrow I might can dump it for you.

from missioncontrol.

@ndeadly on a side note, after some research this problem with the analog on the Switch isn't exclusive to the 8bitdo controllers, it seems to happen in a lot of fake and third party controllers (I think even some PowerA controllers have this problem), I'm starting to think all these Chinese companies are using the same firmware that was reverse engineered with this bug.
Do you think it could be possible to tune the analog sticks to make them work right on Switch mode? If that's a possibility and identifying these fake controllers from the OEM is indeed impossible, I think adding some kind of toggle in the future UI to solve this problem could be possibility. I think solving the root of the problem would be even better than trying to work around by using Xinput.

I know this is not what this homebrew is meant for, but could be a nice option to have.

from missioncontrol.

This is the dump for the SN30 Pro+

I'm not with the SN30 Pro with me right now, but I think tomorrow I might can dump it for you.

Ahh, it appears to be advertising itself as an xbox one controller. I wonder whether it's using the same buttons as one, just with the old button layout. I'll knock you up a custom build with the old layout to see if it changes anything. Do you know if the firmware of these controllers can be updated? Might also be possible to go up to the new format, at that point the controller is for all intents and purposes, and official xbox one controller.

It should be pretty straightforward to make a special case for these controllers that just scales the stick values by some constant. The biggest issue I see is reliably identifying them so as not to screw up any other controllers.

Fyi, I would consider this use case within the scope of the project, just at a somewhat lower priority than some other features at the moment.

from missioncontrol.

Ahh, it appears to be advertising itself as an xbox one controller. I wonder whether it's using the same buttons as one, just with the old button layout.

I assume this is the case for every controller that uses Xinput, right? 8Bitdo controllers have 3 pairing modes:

• Switch Mode (emulates a Switch Pro Controller), this mode is the official way of using this controller with the Switch, it has the analog problems I told you about;
• Xinput Mode (emulates a Xbox Controller), this mode is to be used in PCs, doesn't have the analog problem as far as I'm aware;
• Dinput Mode (don't know if it emulates a controler), this mode is to be used with Android phones, also don't have the analog problems.

So I think the fact the controller is advertising itself as an Xbox controller when I pair it using Xinput is what is supposed to happen, I'm not sure tho because I don't know too much about Xinput.

Do you know if the firmware of these controllers can be updated? Might also be possible to go up to the new format, at that point the controller is for all intents and purposes, and official xbox one controller.

They can, but the firmware all come from 8bitdo themselves, they're known to not do a great job with reverse engineering tho. It seems their firmware is based in the older Xinput firmware for the Xbox controllers, as you pointed out. I don't expect them to fix this ever tho.

It should be pretty straightforward to make a special case for these controllers that just scales the stick values by some constant. The biggest issue I see is reliably identifying them so as not to screw up any other controllers.

Tbh, I think it's impossible to identify them all, the knockoff Switch controllers that have this analog problem just copy the Switch Pro controller, plus their Hardware ID is all over the place, there's zero cohesion even with controllers coming from the same factory. I think having an option in the upcoming Controller Management Application to let the user toggle this correction manually and increase or decrease this correction constant would be the best solution, definetely the easier to maintain.

Fyi, I would consider this use case within the scope of the project, just at a somewhat lower priority than some other features at the moment

Well, if you ever pick this up feel free to ping me and I can help test things around.

from missioncontrol.

Hey, sorry I forgot to get back to you on this. Here's a build where I switched the xbox one button data back to the old format. Maybe it will allow the controller to work in Xinput mode without further modifications.

MissionControl-0.1.0-8bitdo-experiment.zip

from missioncontrol.

Hey, sorry I forgot to get back to you on this. Here's a build where I switched the xbox one button data back to the old format. Maybe it will allow the controller to work in Xinput mode without further modifications.

MissionControl-0.1.0-8bitdo-experiment.zip

Hey mate, sorry for not getting back to you til now, had to deliver couple things at uni.

Anyways, the experimental version works pretty well, the only thing that doesn't work are the screenshot and menu buttoms.

But there's a problem... That problem with the analog sticks persists and it shouldn't as the 8bitdo in Xinput mode don't have this problem, I even double tested it in my computer just to be sure. I'm starting to think this problem might be a little deeper than I thought...

While using MissionControl with Xbox controllers or ps4 controllers is this problem there? I think this might be a problem with the reverse engineering of the Switch Pro Controller (1). I have a Wii Classic controller here but I can't actually test it since there's no L3/R3, therefore I can't actually start the analog stick calibration to see a preview of how the analog is working :/

(1) I have head from a friend that the Pro Controller actually used to have this problem too, but it seems Nintendo fixed it with an update a long time ago. My theory is that when the Pro Controller was reverse engineered this bug from Nintendo came too. I can't actually verify this, because my Switch is pretty recent, but I can verify that the Pro Controller I currently have and my joycons don't have this problem with analogs.

from missioncontrol.

With the old Xbox One controller firmware there was a second report sent for the guide button. Maybe the missing buttons are sent in that one with the 8bitdo. The new format sends everything in a single report so I don't need to handle that other report. Only problem I see here is there might not be any way to differentiate this controller from an actual Xbox One controller to support the different data format. I don't even know how to differentiate between the different Xbox One firmwares to support the old format.

That's strange that you're still getting the issue with the sticks in Xinput mode. Haven't noticed a problem like you describe here with the other controllers. The analog sticks do feel maybe slightly more sensitive but I think that's just due to the different hardware. I wonder if it could be some kind of calibration issue? The switch attempts to read calibration data from the controller when it connects. Currently I just fudge it by sending back all 0xff to the console and it doesn't seem to have any noticeable effect on the other controllers.

You might find this little tool I wrote to be more useful for testing controllers than the builtin calibration features
ControllerTest.zip

from missioncontrol.

With the old Xbox One controller firmware there was a second report sent for the guide button. Maybe the missing buttons are sent in that one with the 8bitdo. The new format sends everything in a single report so I don't need to handle that other report. Only problem I see here is there might not be any way to differentiate this controller from an actual Xbox One controller to support the different data format. I don't even know how to differentiate between the different Xbox One firmwares to support the old format.

I found another problem after that post: the battery seems to be reported always low.
Honestly, ndeadly, I would just drop trying to support Xinput for these 8bitdo controllers, since it doesn't solve the analog problem I think it would be kinda of wasting your time working on these, specially because these already work with the Switch.

That's strange that you're still getting the issue with the sticks in Xinput mode. Haven't noticed a problem like you describe here with the other controllers. The analog sticks do feel maybe slightly more sensitive but I think that's just due to the different hardware.

That is indeed strange. I took the time to download the Controller Test tool and run some tests here with the controllers I have in hand. Here are the results:

The joycons: as you can see, the "+" signal on the screen is on maximum when the stick reaches maximum, as expected. No analog bug.

The SN30Pro+ in Switch Mode: as you can see and as I reported before, this has the analog bug, I drew the axis just in case, as you can see the "+" on the screen is on maximum, but the stick is not, here's a reference of the stick when it's on maximum.

The Wii Classic Controller: as you can see the sticks are perfect for the classic controller just like the joycons. No analog bug.

The SN30Pro+ in Xinput Mode: as you can see, it's showing the same behavior as when the controller is paired in Switch Mode, analog bug is pressent.

So I went and did a test I probably should have done already: I paired the SN30Pro+ in Switch Mode to my Windows 10 PC, as you can see it's recognized as an official Pro Controller. So here is the result:

The SNO30Pro+ in Switch Mode in Windows 10: as you can see, there's no analog bug there

I think It's pretty safe to say the controllers aren't the problem, the problem seems to be in the Switch side for some reason. It's pretty strange because it clearly affects some controllers and others aren't affected at all.

I wonder if it could be some kind of calibration issue? The switch attempts to read calibration data from the controller when it connects. Currently I just fudge it by sending back all 0xff to the console and it doesn't seem to have any noticeable effect on the other controllers.

Tbh I'm not sure, when not using Mission Control and using the SN30Pro+ in Switch Mode I'm actually able to use Nintendo's calibration tool and even after calibrating the problem persists there. But as I showed above, it works fine on windows even when the controller is on Switch Mode. With all these tests any theory I had before about this problem clearly were not valid.

Anyways, this is clearly a rabbit hole xD. As I said, I think it would a better idea to close this issue and open another one focused on the controller stick problem that maybe could be worked in the future.

from missioncontrol.

Thanks for taking the time to conduct some tests and writing up your results. Makes getting to the bottom of these things much easier :)

I'm not quite convinced the stick problem lies on the switch side. I would expect to see issues with other controllers too if there were a problem with the switch interpreting the analog data. Thinking more about it, could this be a deadzone issue? This seems like exactly what I would expect to happen if you had a large outer deadzone applied to the data on the controller side. I came across this reddit thread that implies there's a config application for the controller that allows for the setting of deadzones. Have you taken a look at this?

Edit:
Actually just noticed this line in the post
Even when the outer deadzone is set to the smallest as possible it will still register 100% when only pushing the stick ~80% of the way. Because of this the sticks will be more sensitive than what you might be used to with the Pro Controller

Maybe the PC is just compensating for this when it detects the controller?

from missioncontrol.

Yeah, as you pointed in your edit, setting the deadzone in the 8Bitdo software won't solve it sadly.

Maybe the PC is just compensating for this when it detects the controller?

Could be: I went ahead and paired it as Pro Controller in my Android phone and downloaded a gamepad testing app, result is the same as windows: no analog bug. If this is some kind of compensation, it happens in both windows/linux and android. I'm out of ideas of what this could be tbh.

from missioncontrol.

Damn. Only other thing I can think of is it has something to do with the calibration data stored in the SPI flash and the switch isn't applying it or something. That could explain how I'm able to get away with sending it garbage data without any noticeable effect.

Anyway, I think it's probably best to revisit this once I've improved the controller detection or implemented per-controller configs. No point in thinking about how to correct the stick data if there's no way to tell it apart from an official Switch Pro or Xbox One controller.

from missioncontrol.

Anyway, I think it's probably best to revisit this once I've improved the controller detection or implemented per-controller configs. No point in thinking about how to correct the stick data if there's no way to tell it apart from an official Switch Pro or Xbox One controller.

Totally agree. Let me know when you revisit this and I'll be sure to help testing things around.

Cheers!

from missioncontrol.

You should be able to use these controllers with switch mode on the new release.

from missioncontrol.

Hey ndeadly, what's exactly supposed to be different from the version 1 to 2 with these controllers? The analogs got tweaked somehow or by using you mean just connecting and using them as I was doing without MissionControl?
Cheers!

from missioncontrol.

Yeah I just meant as you were without MissionControl. You can ignore this if you already had this working (sorry didn't have time to read back through our discussion). Many users had issues with 3rd party Pro Controllers after installing MissionControl so I was just going through my issues giving everyone a heads up.

I was able to work around the need to store controllers to the database under the name Pro Controller so any controller with that name can now actually be trusted to be one (or at least pretending to be one). This means you could clear the database and pair again and see if the 8bitdos use a different name or anything I might be able to use to differentiate from the official controllers they are trying to impersonate. If so I might be able to solve your stick issue sooner than we though.

from missioncontrol.

Yeah, I see. I heard a lot about this problem with pro controllers refusing to pair, glad it's solved!

This means you could clear the database and pair again and see if the 8bitdos use a different name or anything I might be able to use to differentiate from the official controllers they are trying to impersonate. If so I might be able to solve your stick issue sooner than we though.

Sadly it shows as Pro Controller, 8bitdo really did everything to make our lifes harder, lol.

Thanks for the heads up, ndeadly!

from missioncontrol.

Sadly it shows as Pro Controller, 8bitdo really did everything to make our lifes harder, lol.

What about XInput mode?

from missioncontrol.

On Xinput it actually changes name to 8BitDo SN30 Pro+

from missioncontrol.

There we go. We can differentiate it from the official Xbox One controller then at least.

from missioncontrol.

I see, that's some good news at least 😂

from missioncontrol.

Hi, are you Using the 5.00 firmware? 8bitdo solves several issues on that firmware.

from missioncontrol.

Hi, are you Using the 5.00 firmware? 8bitdo solves several issues on that firmware.

Just updated and as expected the problem is still there.

from missioncontrol.

Yes your are right with firmware the problem still happen, and trying to calibrate the controller on Switch system menu fails, I think the switch send the calibration data to the controller but the 8bitDo obviously doesn't understand or handle the write back correctly, I just open a support case on 8BitDo, hope some light come from they. thanks all you for the hard work testing and developing.

from missioncontrol.

Yes your are right with firmware the problem still happen, and trying to calibrate the controller on Switch system menu fails, I think the switch send the calibration data to the controller but the 8bitDo obviously doesn't understand or handle the write back correctly, I just open a support case on 8BitDo, hope some light come from they. thanks all you for the hard work testing and developing.

Sadly people have been reporting this problem to them for years, it seems most users never actually noticed this, specially the youtubers that shill review these 8bitdo controllers and say they're "the real pro controllers". I'm yet to see a single reviewer talking about this problem, and I'm 100% sure the sn30 pro+2 or whatever it's called will have the same problem, all of their switch controller have it.

In my case I decided to buy a oem pro controller and sell the 8bitdo one :/. So in my case: problem solved.

from missioncontrol.

Waw. Dude, that's is a lot of effort on diagnosing, thanks

from missioncontrol.

These controllers should now work correctly in XInput mode with the new 0.5.0 release https://github.com/ndeadly/MissionControl/releases/tag/v0.5.0

Switch mode will require action from 8bitdo, however

from missioncontrol.

Just found this issue and wow what a clean back and forth that was. Thanks a lot @ndeadly and @evertonstz, great attitude and work!

from missioncontrol.

Cheers @scalp42 . Are you able to confirm that the new release does in fact solve the issue for 8bitdo controllers?

from missioncontrol.

@ndeadly I haven't ordered one yet, was doing preliminary work 😅

from missioncontrol.

Ah I see. Well, I'm confident the issue should be resolved with the latest mission control version, but always good to get a first hand confirmation.

from missioncontrol.