8bitdo DIY Kits (NES, SNES, N64) not resyncing after cold reboot / powercycle on MiSTer v230423 OS v230501

[drtekGER]

After updating to MiSTer v231018, OS v231108 my 8bitdo DIY BT Controller Kits (N64, NES, SNES) will not resync after a cold reboot / power cycle.

Going back to MiSTer v230423, OS v230501 everthing is working / resyncing fine again.

[drtekGER]

Keeping MiSTer v231018 while reverting OS to v230501 is fixing this issue.

[birdybro]

Do those controllers have a Nintendo Switch mode? If so, switch from that mode to XINPUT instead and see if the behavior continues.

[drtekGER]

I did test that. Only reverting to OS v230501 is fixing this issue.

[birdybro]

If you unplug and then plug in the bluetooth adapter you are using after the cold reboot, does it pair?

[drtekGER]

No it doesn't. Need to re-pair after every power cycle / cold reboot no matter if unplugging or not. OS v230501 is working flawless.

[Sheeg]

I did test that. Only reverting to OS v230501 is fixing this issue.

Are you absolutely certain? The new drivers added are only for Switch controllers, no other driver changes (aside from gamecube adaptor and stadia, which shouldn't be relevant here) are included between those versions. If those controllers are using Nintendo vendor ID + device ID in other, non-switch modes that would be a problem, we would need to find some way to differentiate from actual Switch controllers.

[drtekGER]

Hi, yes I am 100% sure Tested on two different Misters. 8bitdo DIY Kits not resyncing after v230501. Had to buy new controllers. Shig ***@***.***> schrieb am Do., 28. Dez. 2023, 00:44:

…

I did test that. Only reverting to OS v230501 is fixing this issue. Are you absolutely certain? The new drivers added are only for Switch controllers, no other driver changes (aside from gamecube adaptor and stadia, which shouldn't be relevant here) are included between those versions. If those controllers are using Nintendo HID + device ID in other, non-switch modes that would be a problem, we would need to find some way to differentiate from actual Switch controllers. — Reply to this email directly, view it on GitHub <#856 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALIUWYEPNEUNQUQHJ66TMLDYLSXHDAVCNFSM6AAAAAA77AWAWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZQGY4TKOJQGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[SeongGino]

So while I can't speak for the other mod kits, I can at least verify that the N64 Mod Kit in particular is having some issues.

Bluetooth behavior is all but identical from my end - only works the first time it's paired, disconnecting and reconnecting makes it unable to connect without a power cycle. No other bt devices in my setup have this particular issue.

When plugging in a USB cable, when it's under Switch mode, it uh... causes the kernel to start dividing by zero?

Nothing ever gets recognized, and the kernel logs just spams this until it's disconnected (as well as mentioning things about leds 0003:057E:2009.0001:player1: Setting an LED's brightness failed (-71)).

When plugged in via Dinput/generic mode, while it can be seen and works somewhat initially, attempting to map the controller causes problems:

• When testing sticks at the start of controller configuration, the usual "Stick 1 Right" gets skipped, and goes straight to "Stick 1 Down"
• Nothing more than D-pad up and right are recognized, so the controller is rendered effectively useless to configure.
• It also doesn't help that the C-Buttons all act as a right analog stick, so in theory this would mean potential for SOCD issues where opposites cancel each other out.

From what I can tell in my Linux system, when in Switch mode, the Mod Kit emulates a Nintendo Switch Pro Controller verbatim - meaning it uses the exact same name, VID and PID identifiers as a genuine Switch ProCon. This is a bit of an issue, as it obviously means at face value, it has to share ProCon values, which changing would break real Pro Controller functionality. However, Switch mode seems to be the only way to get the Mod Kit's rumble pack to work - as it otherwise doesn't seem to be exposed over generic input mode. Generic input also means that the Star button (on the Pak) isn't available, and Z (trigger) and ZR (on the Pak) are in unconventional places that aren't recognized by SDL apps.

Ideally, the controller should work in Switch mode, so that at least rumble can be properly exposed in supported cores. But just getting it to work at all would be a nice start, as inconvenient as this all sounds given the circumstances explained...

[sorgelig]

You need to understand that support for different controllers such as Switch, PlayStation, etc, is non-official. So driver is written by enthusiasts by analyzing the work of original controller. So it doesn't expect much deviation from work. And those 3rd party controllers pretending to be a Switch/PS controllers are quite different in work. It breaks the work of driver.

[SeongGino]

You need to understand that support for different controllers such as Switch, PlayStation, etc, is non-official. So driver is written by enthusiasts by analyzing the work of original controller. So it doesn't expect much deviation from work. And those 3rd party controllers pretending to be a Switch/PS controllers are quite different in work. It breaks the work of driver.

I do, in fact, understand what volunteer work is, thank you. I'm just explaining the situation since it hadn't been done so in detail up till now.

And all I do know is that my desktop Linux kernel doesn't start trying to divide by zero when I plug the mod kit into my PC, Kernel 6.10. Even if it is pretending to be a Pro Controller (which is uncool, but I 'get' why 8bd does it), it would be nice to have it working in a basic capacity on MiSTer.

[sorgelig]

Because there are much more devs in Linux PC. Also, the same driver may behave differently on PC and MiSTer by various reasons. And unlike Windows, you can't simply copy driver from one kernel to another because kernel structures are often get changed, so it's not as simple as you think.
Usually, fixes are coming from various users who may have specific device and are willing to fix the problem by themselves and share with community.

[offalynne]

torvalds/linux@6eb04ca

[sorgelig]

ok, try this build then:
zImage_dtb_t1.zip

[offalynne]

@drtekGER @SeongGino

[SeongGino]

Tried the new image, which does resolve the dividing by zero error.

However, trying to connect it over USB in Switch mode, it is recognized as a Switch ProCon, but there's no Input event-style feedback when pressing any of the buttons. And after some time, both LEDs (red on the rubber gasket, blue on the Pak) turn off.

The file event2 was created.
The directory by-id was created.
The directory by-path was created.
Close all devices.
Open up to 30 input devices.
make_unique(289B,0057,-1)
make_unique(0E8F,3013,1)
make_unique(16C0,05E1,1)
make_unique(045E,02A1,1)
make_unique(8282,3201,1)
make_unique(1209,FACA,1)
make_unique(16D0,127E,1)
make_unique(1209,595A,1)
opened 0( 0): /dev/input/event1 (057e:2009:03d837d9) 0 "E4:17:D8:F4:8F:1B" "Nintendo Switch Pro Controller"

So it seems like, at least with wired connection, there's still something else missing for it to be functional.

---

When trying to connect over Bluetooth in Switch mode, it works fine when paired once. Luckily, it also uses a unique identifier: "Nintendo N64 Controller" with ID 057E:2019.

But when reconnecting to a paired MiSTer any point, even after reboots, only this comes up:

[   24.287270] nintendo 0005:057E:2019.0002: failed reading SPI flash; ret=-110
[   26.335266] nintendo 0005:057E:2019.0002: failed reading SPI flash; ret=-110
[   28.383269] nintendo 0005:057E:2019.0002: failed reading SPI flash; ret=-110
[   30.431289] nintendo 0005:057E:2019.0002: failed reading SPI flash; ret=-110
[   32.479265] nintendo 0005:057E:2019.0002: failed reading SPI flash; ret=-110
[   34.527268] nintendo 0005:057E:2019.0002: failed reading SPI flash; ret=-110
[   36.575276] nintendo 0005:057E:2019.0002: Failed to set report mode; ret=-110
[   36.584135] nintendo 0005:057E:2019.0002: probe - fail = -110

However, this seems to roughly line up with behavior on upstream Linux 6.10:

• Initial pairing:

[ 8881.420178] nintendo 0005:057E:2019.000C: hidraw6: BLUETOOTH HID v80.01 Gamepad [N64 Controller] on f0:77:c3:4c:da:d7
[ 8881.531754] nintendo 0005:057E:2019.000C: controller MAC = E4:17:D8:F4:8F:1B
[ 8881.686755] nintendo 0005:057E:2019.000C: using factory cal for left stick
[ 8881.843754] nintendo 0005:057E:2019.000C: using factory cal for right stick
[ 8882.590770] nintendo 0005:057E:2019.000C: assigned player 1 led pattern
[ 8882.754869] input: N64 Controller as /devices/virtual/misc/uhid/0005:057E:2019.000C/input/input25

(and will occasionally output nintendo 0005:057E:2019.000C: joycon_enforce_subcmd_rate: exceeded max attempts but it does work)

• Subsequent connection after pairing:

[ 8934.118247] nintendo 0005:057E:2019.000D: unknown main item tag 0x0
[ 8934.118484] nintendo 0005:057E:2019.000D: hidraw6: BLUETOOTH HID v80.01 Gamepad [N64 Controller] on f0:77:c3:4c:da:d7
[ 8936.198042] nintendo 0005:057E:2019.000D: Failed to get joycon info; ret=-110
[ 8936.198045] nintendo 0005:057E:2019.000D: Failed to retrieve controller info; ret=-110
[ 8936.198047] nintendo 0005:057E:2019.000D: Failed to initialize controller; ret=-110
[ 8936.198103] nintendo 0005:057E:2019.000D: probe - fail = -110
[ 8936.198112] nintendo 0005:057E:2019.000D: probe with driver nintendo failed with error -110

So with BT, it looks like some fixes are needed upstream.

[sorgelig]

I cannot find repository now where nintendo/switch driver is developing (not related to MiSTer), but as far as i know many 3rd party controllers are fail, including 8bitdo. You have to switch 8bitdo to x-input or d-input mode if you want to use it with MiSTer. I have several 8bitdo controllers - i use them in X/D-input mode only.
Or.. use original Nintendo Switch controller.

[SeongGino]

Or.. use original Nintendo Switch controller.

Sure, if someone was willing to spend $100 on an NSO controller, either thru secondhand or buying it + an NSO subscription, instead of the mod kit because it was cheaper. 😉

/ot

I'm fairly certain any hid-nintendo development is in the upstream Linux kernel now since it was mainlined back in 5.10 iirc. Not that I personally would know where to start looking wrt this issue/controller specifically; I understand if this isn't a priority or anyone else is interested in a resolution to this problem.