In case you have not found it yet by yourself: [1] discusses this.

TL;DR you will need some extra circuits (monostable circuit or timer IC NE556) to do this.

And in addition to the StackExchange post you will also need a circuit for the falling edge of the latched switch.

Then you can use the "momentary switch approach" [2]

[1] https://electronics.stackexchange.com/questions/589099/converting-latching-switch-to-momentary-output
[2] https://raspberrypi.stackexchange.com/questions/77905/raspberry-pi-3-model-b-dtoverlay-gpio-shutdown#77918

@papichulo I messed up my forum notification settings and I am sorry for this! I am replying just in case this is still an issue for you:

Maintained/latching switches for on my site with the ControlBlock rev. 3.4. Do you have any any special hardware setup? The ControlBlock switches from maintained/latching mode to momentary switch mode, if a logic low signal is observed within 2.5 seconds after pressing the switch for switching the Pi on. Do you observe the same behavior when you replace the button by simple jump wires to simulate a maintained button?

@mitu Well ... looks like you are right. :D

Edit:
Fixed! ;)

@Unknown All good. I should have been more specific, as this is a relative new and unknown feature on Yuzu. @mitu explained it a bit already. Currently Yuzu does what basically every emulator does and emulates the CPU in its entirety. That is very slow and the reason why we need powerful and modern computers to do this. Now the CPU on Switch is an ARM architecture and is very similar to what you find in an Android phone. What they can do is, instead emulating every CPU command, they can utilize what's already there and run parts of it native. They also call it "Project NICE" (not sure where the i comes from in NCE, but it sounds nice).

Here is my question: Does this apply to Raspberry Pi 5 with Linux as well or is it limited to Android devices? I don't know if these ARM architectures are similar enough. EDIT: I just looked up specs and the Switch CPU is an "ARM 4 Cortex-A57" and the Raspberry Pi 5 has an "Arm Cortex A76".

@duglor I think you could do quick menu > controls > port 2 controls > mapped port: 1 and then save it as a game or core remap file. Do this for each game or core that requires it.

@ras_oscar
One more thing to note. While this may be a method to back up a game for your console, it won't work on any other switch console as the files are digitally signed. If you want to create a more universal type of backup you will need to look into homebrew.

If you just have something like the following in your views.xml, EmulationStation does not know where to use it:

<text name="labelPublisher" extra="true"> <origin>0 0.75</origin> <pos>0.681 0.264</pos> <fontSize>${fontSizeSmall}</fontSize> <alignment>left</alignment> <fontPath>${fontMain}</fontPath> <color>${textColorAlt}</color> <text>Publisher:</text> </text>

So, it needs to be inside a view tag:

<view type="detailed, video"> <text name="labelPublisher" extra="true"> <origin>0 0.75</origin> <pos>0.681 0.264</pos> <fontSize>${fontSizeSmall}</fontSize> <alignment>left</alignment> <fontPath>${fontMain}</fontPath> <color>${textColorAlt}</color> <text>Publisher:</text> </text> </view>

Wow so cool looking forward to the finished product!

@upjumptheboogie

I love controllers and I play with a lot of them. Heck, I just ordered two of them today just because I haven't tried them before. Unfortunately, I don't have alot of experience using the Nintendo online controllers with a raspberry pi box. While I cannot tell you specifically, I caution you when using fairly niche controllers that the user base may not have mocked up some drivers for.

You are generally safe when using simple plug and play types and also Xbox clones because those drivers have been well tested.

After using dozens upon dozens of controllers for retro gaming there are a few that I keep coming back to, but your milage may vary.

I tend to use iBuffalo controllers for NES and SNES. Unfortunately, those are absurdly expensive right now. I got several when they were $15 USD, but they are going for over $40 now.

For Playstation I usually use a Logitech F710 as I like the micro switches in the d-pad. It's kind of like a Sega style disk but with four clicky switches under it.

For Genesis/MD I will either use an iBuffalo or a Retrobit Dual-link six button controller. There are several really fancy looking Gensis/MD six button clones on Amazon, but for some reason a lot of them have trouble reading when two buttons are pressed at the same time. The Dual-links seem to not have this issue.

8bitdo is another premium option, but I personally dislike how they feel. The buttons tend to be pretty great, but the d-pads seem to have a weird springy sponge quality to them.

I've tested myself using multiple controllers in challenging sections of Contra. Oddly enough, the controller I did the best with was a standard Xbox One controller with that clicky d-pad. But the buttons on that one feel awful to mash.

Ultimately, finding a controller that feels right to you is the important part. I know a guy that can do a no death run of Ninja Gaiden NES with a wretched old Xbox 360 controller. Trying to use the d-pad on that thing raises my blood pressure. But to each their own, Good luck!

Yeah I use my switch pro controller, I havent done any extra configuration at all and it pairs just fine. Can you try another bluetooth controller? Dualshock 4 or Xbone one controller?

If this is your first time pairing via bluetooth, you might want to check that your bluetooth is working correctly with this command in the terminal:

systemctl status bluetooth.service

@efriim said in Nintendo Switch Online, Super NES controller.:

I can get them to register/sync in Bluetooth but after I disconnect them I have to redo it in the Bluetooth menu to get them to sync again.

Not sure what you mean by 'disconnect them'. I usually just shutdown RetroPie / Emulation Station and the controllers go to sleep on their own.

I use Switch Pro controllers and mine will stay synced to my RetroPie install as long as I don't plug them into the Switch to charge them. Charging through the Switch will automatically re-pair the controller to the Switch and it won't talk to anything else without a manual re-pairing.

The controller/player number lights on the controller constantly array as if it is still syncing, or as if it can't assign the player number in the controller.

I don't have a solution but my Pro controllers do the same thing so it is somewhat normal for this style controller. I think you are right that the Switch must send information back to the controller to tell it which player number it is assigned and nothing in the RetroPie package will do that at this point.

https://github.com/pyhammond/retropie_wiimote_lights
This project was for Wii controllers but maybe it holds the answer and can be adapted.

Try updating RetroPie and the OS/packages to the latest version and re-try the pairing via Bluetooth.

@zantetusken10 I think the problem is joycond. I uninstalled it (manually deleting the files it installed + disabling the service) and now it works. The only quirk are the leds of the controller. For example, if I connect it with bluetooth the first time the first light will be on, if I disconnect and reconnect via bluetooth, the first + second light will be on like if it were player 2, but the controller will work fine nonetheless.

Now, to get it to pair properly with Steamlink :D

If the switch maps ZR/ZL to axis (instead of buttons), then EmulationStation (where I assume you try to register them) will ignore them as buttons. Have you tried to map them to LT/RT (the should trigger buttons) ?

Just to give a conclusion to the thread, I tried a whole bunch of stuff. I tried jscal, evdev-joystick, updating the kernel, downloading some different files... but ultimately, this is what worked:

https://retropie.org.uk/forum/post/227102

I installed hid-nintendo as described in the post and everything just worked like it was supposed to after rebooting the machine. It makes you reconfigure the controller, but after that, it just works.

Hi, sorry for this delayed reply.

I can confirm that the GPIO terminal pins as well as the USB ports do not serve power when the Pi is shut down with the PowerBlockling. I just tested it (again) with a Pi 4.

Hope that helps!