Homebrew RELEASE MissionControl: Use controllers from other consoles natively via Bluetooth

  • Thread starter Thread starter ndeadly
  • Start date Start date
  • Views Views 381,622
  • Replies Replies 1,400
  • Likes Likes 172
Blinking goes on steadily for about 15 secs. until it stops trying. I know what you mean, but it doesn't do anything
I don't know about the WiiMote 1+2 syncing. It has always worked and syncing as/like a normal WiiU Pro controller on the WiiU.
I bought the 8bitdo dongle to use that particular controller, but it wouldn't take it either. So I was happy to see MissionControl could extract the id of it in hopes of supporting it in the future. Seems that might not be so easy after all.

I'm assuming getting the id/mac from somewhere else (if possible) wouldn't help, since it apperantly doesn't even try to talk with the Switch, or?
If you have any other means of pairing the controller and reading it's information, this may help. I just double-checked my source code and remembered that it uses the device name to decide which pincode to send. If your knockoff has some other name (official controllers begin with "Nintendo RVL"), then this would cause it to send the wrong pin and fail.

Eventually I might implement pairing in my companion app to allow people to observe the process for diagnosing these kind of issues. For now, if you could extract this information via some other means I may be able to help you more quickly
 
  • Like
Reactions: lordelan
If you have any other means of pairing the controller and reading it's information, this may help. I just double-checked my source code and remembered that it uses the device name to decide which pincode to send. If your knockoff has some other name (official controllers begin with "Nintendo RVL"), then this would cause it to send the wrong pin and fail.

Eventually I might implement pairing in my companion app to allow people to observe the process for diagnosing these kind of issues. For now, if you could extract this information via some other means I may be able to help you more quickly

I don't know anything about it, but let me see if I can find anything that can read some data about it...
If anyone knows a way, please let me know.

Thanks for taking the time, btw.
 
Hello, here is my DS4 fix.
if (src->input0x11.usb && src->input0x11.battery_level < 11)
m_charging = true;
else
m_charging = false;
m_battery = src->input0x11.battery_level*9/10;
No longer crash even at max battery regardless of usb status.

But...
It still shows charging even when battery is full.
https://android.googlesource.com/kernel/common.git/+/brillo-m9-release/drivers/hid/hid-sony.c
That link above says DS4 should be:
11 when charged and plugged in.
9 max when on battery.

But that seems to be not the case here.
Directly plugging in the value to the m_battery will result in crash at max battery, even without usb plugged in. Setting the m_battery manually to 9 does not crash the switch. Hmm...

I am a noob here and I am wondering if debugging is possible.
 
Hello, here is my DS4 fix.
if (src->input0x11.usb && src->input0x11.battery_level < 11)
m_charging = true;
else
m_charging = false;
m_battery = src->input0x11.battery_level*9/10;
No longer crash even at max battery regardless of usb status.

But...
It still shows charging even when battery is full.
https://android.googlesource.com/kernel/common.git/+/brillo-m9-release/drivers/hid/hid-sony.c
That link above says DS4 should be:
11 when charged and plugged in.
9 max when on battery.

But that seems to be not the case here.
Directly plugging in the value to the m_battery will result in crash at max battery, even without usb plugged in. Setting the m_battery manually to 9 does not crash the switch. Hmm...

I am a noob here and I am wondering if debugging is possible.
Saw your update on github. Will look over it and compare to how linux kernel handles it when I have time later today.

I will make a build with logging enabled in the next few days to help people diagnosing issues
 
  • Like
Reactions: r5xscn
I haven't read the whole thread... Is there any chance to use this on SX OS?

I will probably eventually switch to atmosphere when it gets a fully completed release.

Also is there any chance you can add a option to emulate the gamecube controller so that we can use analog triggers in the supported games like GRID??????????
 
Random thought, do controllers with analogue shoulder buttons have them recognised as such? Like they might work with Retroarch etc? Or are they treated like the Switch's standard digital buttons?

E: hehe posted about analogue triggers at the same time someone else did :grog:
 
I haven't read the whole thread... Is there any chance to use this on SX OS?

I will probably eventually switch to atmosphere when it gets a fully completed release.

Also is there any chance you can add a option to emulate the gamecube controller so that we can use analog triggers in the supported games like GRID??????????
I am not an SXOS user and can't offer support, but I don't think anyone has got it working. Not much I can do about that. Not trying to alienate any users, just using the best tool for the job.

Random thought, do controllers with analogue shoulder buttons have them recognised as such? Like they might work with Retroarch etc? Or are they treated like the Switch's standard digital buttons?

E: hehe posted about analogue triggers at the same time someone else did :grog:
I don't think the switch has any concept of analogue triggers so this probably isn't possible, at least not with regular switch software that reads its inputs through the hid module. It would be possible with homebrew if someone were willing to put in the effort to do the input handling manually, and use my btdrv-mitm module to steal the bluetooth events from the system. It's kinda cursed but it would work.
 
I don't think the switch has any concept of analogue triggers so this probably isn't possible, at least not with regular switch software that reads its inputs through the hid module. It would be possible with homebrew if someone were willing to put in the effort to do the input handling manually, and use my btdrv-mitm module to steal the bluetooth events from the system. It's kinda cursed but it would work.

It has the concept somewhere because there are a few racing games that can read analog trigger values from gamecube controllers. Not sure if that can apply to wireless though.
 
Last edited by Rahkeesh,
I am not an SXOS user and can't offer support, but I don't think anyone has got it working. Not much I can do about that. Not trying to alienate any users, just using the best tool for the job[\QUOTE]

So you are practically saying there wouldn't be SX support, then?
 
I haven't read the whole thread... Is there any chance to use this on SX OS?

I will probably eventually switch to atmosphere when it gets a fully completed release.

Also is there any chance you can add a option to emulate the gamecube controller so that we can use analog triggers in the supported games like GRID??????????

Currently the code has Atmosphere libs dependencies until someone figures out how to do it without them no SX support (I'm a SXOS user myself)
 
It has the concept somewhere because there are a few racing games that can read analog trigger values from gamecube controllers. Not sure if that can apply to wireless though.
Oh interesting, didn't know that. Got any further info? Which Gamecube controllers can be connected to the Switch?

So you are practically saying there wouldn't be SX support, then?
MissionControl is written with Atmoshere-libs because it's designed for exactly this kind of task. I'm sorry, I have nothing against the users, but it's not really my problem if TX can't/won't support it. They've proven themselves quite capable of taking Atmosphere code for their own in the past. If someone wants to figure out a way to make it work, or rewrite the project to remove the dependency, go for it. I have no intentions to rewrite it without, and no means to test whether it works regardless.
 
Now all of a sudden the next version of SXOS have 3rd party wired and wireless controller support (missioncontrol and sys-con baked in) :rofl2::rofl2::rofl2:

MissionControl is written with Atmoshere-libs because it's designed for exactly this kind of task. I'm sorry, I have nothing against the users, but it's not really my problem if TX can't/won't support it. They've proven themselves quite capable of taking Atmosphere code for their own in the past. If someone wants to figure out a way to make it work, or rewrite the project to remove the dependency, go for it. I have no intentions to rewrite it without, and no means to test whether it works regardless.

I think that regardless of what was written on missioncontrol is a great homebrew and an AWESOME CONTRIBUTION to the community. Kudos to you @ndeadly
:grog::grog:


They are a ton of avid devs out there including the TX people itself as you pointed out who could port it to SXOS.
 
Last edited by thedizzy90,
Wow, you’re a genius sir, thank you so much!!! I almost buy a pro controller this week (it’s expensive as hell here).
 
  • Like
Reactions: lordelan
THANK YOU BRO !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
  • Like
Reactions: MUDD_BR

Site & Scene News

Popular threads in this forum