8BitDo Bluetooth Gamepads fail in Xinput

[ToniBC]

I also put it here because I think something interferes with some adjustments that were made in the latest firmware 1.32 of this gamepad in the Retroarch interface or in the mGBA core.

According to their log they adjusted the following in 1.32 and 1.33 firmware:

1. Fixed the latency issue when using with Switch Joy-cons attached.
2. Support USB connection on Switch mode.
3. Enhance the accuracy of joystick.

Well, with the previous version, 1.31, everything works correctly, but with the new one, 1.32 or 1.33, the core of mGBA is very slow. It only happens with mGBA, with the rest of cores it works correctly, so I suppose it is a core or interface failure.

That is, if I connect the controller and start the mGBA core, it goes very slow, but if you stop the gamepad it works normally and when connected again with the game running it happens again. This fault does not happen if you connect the controller in dinput mode, it only occurs in xinput mode and with firmware 1.32 or 1.33.

I don't know if it's a controller firmware bug or any option or setting in the retroarch driver that interferes with mgba only, but it seems very rare that it only affects the mGBA core and the others don't.

Thank you.

[endrift]

I have a theory that this might be due to how I handle rumble in the core, but I have no evidence to back this up yet. Will need to do some testing.

[ToniBC]

The same thing happens to me about the other user @Ludhelm in #1638, it happens with mGBA and some other core. It seems to be what he says of the 50 hz, but it only happens with the latest gamepad updates, I have it at 1.31 and it is perfect, but if you update the firmware, something changes and seems to affect the controller of the Retroarch controller. But since it only affects certain cores, it is somewhat complicated to find unless you have a gamepad of these to replicate the problem.

[endrift]

I do in fact have one of these controllers. What other cores are affected?

[Lo0twig]

None. mgba only.

[endrift]

@ToniBC said it affects other cores though. In any case, I've confirmed my theory that it's because of rumble. This doesn't appear to be fixable on the mGBA side without removing rumble outright. This may be a bug in RetroArch itself, or it may not be fixable without a firmware update on the controller side. CC @twinaphex

[Ryunam]

Just bringing this up again, I have experienced the same issue with another device from 8bitdo: the SN30 Pro+ (latest firmware), connected in Xinput mode through Bluetooth.

Upon starting any content with the latest mGBA core and this controller set to Xinput mode, both video and audio slow down to a crawl. Everything starts stuttering to the extent of making all content unplayable. If the controller is otherwise set to Dinput mode, the core works normally.

I have also tested several other cores to see if I could reproduce the same issue elsewhere (as per @ToniBC's observation). I have tried this with both cores that support rumble and others that do not support it:

• Nestopia
• Gambatte
• snes9x
• bsnes (several variants)
• Beetle PSX (both software and hardware)
• Mupen64Plus-Next
• Parallel N64

None of the above had this problem. All the cores listed here performed the same irrespective of whether this controller was set to Xinput or Dinput mode. Based on these tests, I think the issue actually affects the mGBA core exclusively.

[Ryunam]

I stand corrected: upon further testing, it seems that with these 8bitdo controllers the Beetle PSX software core has exactly the same problem when loading a game that supports vibration (content slowing down to a crawl). On the other hand, Beetle PSX Hardware with the Vulkan renderer seems to ignore vibration altogether.

The only core with rumble support that is working fine with these controllers is Mupen64Next-Plus.

[Sanaki]

This may be related to libretro/RetroArch#10408 in some way. EDIT: I seem to have identified the cause of that issue, it no longer seems like it could be related.

[Ryunam]

@Sanaki I'm not getting any slowdown when starting up RA or when loading a core that does not support rumble, while I can see that you've had issues even with snes9x. So I think that https://github.com/libretro/RetroArch/issues/10408 might have more to do with Bluetooth support for the Xbox One S controller on Linux (I use Windows 10).

On the other hand, this is most definitely something weird with rumble support specifically. In fact this issue does not happen if you set the SN30 Pro+ to Dinput mode, which does not support vibration at all. Interestingly enough, Mupen64Next-Plus seems to be the exception.

[Sanaki]

I merely used snes9x as a test. The issue affects load times in retroarch itself. It may be that the way retroarch handles the controller on Linux is initializing rumble before the core even gets to that point. While the issue is directed at the Xbox One controller, I reproduced it using the 8bitdo SN30 Pro+ controller.

That said, it was just a guess. I can't actually reproduce -this- issue on Linux RetroArch and mGBA with the 8bitdo SN30 Pro+ via bluetooth. Once the core actually loads, I'm getting full speed. Uncapped framerate in the realm of 600 fps.

[Ryunam]

Interesting, thank you actually, because you made me realize an element that I had not considered before. This issue only happens with these controllers connected through Bluetooth.

I have the SN30 Pro Plus (that's the one I'm using to document this issue) and if I set it to Xinput and connect it through USB everything works fine once again. Both the mgba and Beetle PSX core do not exhibit any problem if the controller is connected through a cable, but the issue resurfaces again with Bluetooth.

So something weird is going on with either vibration support within the controller itself (in Bluetooth Xinput mode, perhaps in Windows 10 only?) or with the implementation in the mgba and beetle-psx cores that makes the controller go crazy and slows down everything to a crawl...

[ToniBC]

Apparently, with other tests carried out by a friend, with the BT adapter (TP Link) the controls of (8Bitdo) fail in mGBA, but with the BT (8bitdo) it does not fail, curious.

The BT adapter (8Bitdo) is Bluetooth 2.1, Class 2 and the others are all 4.0 or 5.0. It could be something related to that, I need to check in a few days that the adapter arrives to test also. But as I commented, mGBA and other not now do not remember was wrong.

[Ryunam]

Yes, I can confirm that with the official 8Bitdo adapter (the one shaped like a red brick) this issue does not happen. The slowdown only occurs when connecting the SN30 Pro or the SN30 Pro + to a Bluetooth dongle or integrated Bluetooth card. I tried this also with a Surface Pro 6 and it's exactly the same: when you connect the controller via Bluetooth in Xinput mode, it causes a slowdown on both the Beetle PSX and mgba cores.

I believe it could have to do with the fact that the 8Bitdo adapter actually simulates a wired Xbox 360 Controller and is not identified in the OS as a Bluetooth device.

I wrote to 8Bitdo Customer Support about this issue, so hopefully we see some new development or updated firmware on their front.

[endrift]

I've skimmed through the rumble code in RetroArch for Xinput and it's simple enough that I'm 99% sure that it's just outright a bug in the firmware that will be difficult to work around, and may not be worth working around since it's a bug in their code. It's also possible it's a bad interaction between their code, Bluetooth latency, and Windows' Bluetooth stack. I've seen weird lagging issues in commercial games when official Xbox One controllers go on the fritz (usually due to low battery or being close to out of range).

[Ryunam]

Thank you @endrift for for intervening in this issue (and by the way thank you actually for all the hard work poured into developing mgba. It's absolutely amazing).

It's likely to be a firmware issue and in fact I'm waiting for 8Bitdo to hiopefully fix this problem on their end, however I'm still wondering why this is not happening with neither the Mupen64Plus-Next libretro core (and just that one core apparently), nor all sorts of other games and content outside of libretro (Steam games for example).

I am not sure what is it that Mupen is doing differently here with regards to rumble.

[ToniBC]

So report the error, because if it were generic, it would fail in everything, but only some cores are affected. Snes9x and almost all of them seem to work correctly except for 2 or 3, so it makes you think that these cores read the controls differently.

[detectorcaleta1]

Hello, I am the one who carried out all the tests with 2 bluetooth adapters that I have and with the 3 controllers, the Xbox One, the PS4 and the SN30 Pro Plus with the TP Link brand bluetooth. When I connect the 2 controllers (Xbox One and PS4) and test the mGBA core, there is no problem at all, the sound is fine, but when I connected the TP Link bluetooth with the SN30 Pro Plus controller, there yes, the sound is terrible when I run the mGBA core.

When I connected the other bluetooth, the 8BitDo brand with the 3 controllers (Xbox One, PS4 and SN30 Pro Plus) and I run the mGBA core, everything is perfect. In conclusion, the problem with the sound in the mGBA core happens when I connect the TP Link bluetooth with the SN30 Pro Plus.

I tried only the Donkey Kong game for Game Boy Advance and I think with the other games the problem is going to be the same, because when I paired the TP Link bluetooth and SN30 Pro Plus produce that input lag and screw up the mGBA core.

I tried the Snes9x core with the 3 controllers and the 2 bluetooth (Bluetooth TP Link: Xbox One, PS4 and SN30 Pro Plus) (Bluetooth 8BitDo: Xbox One, PS4 and 30 Pro Plus) and everything perfect. The mGBA core is being affected by the SN30 Pro Plus and the TP Link bluetooth paired.

I updated RetroArch to the date of April 21, Nightly, I also updated the two APIs, Vulkan and GL, I updated the cores, everything, etc.

Have a nice day guys.

[ToniBC]

I think that at the moment everything works correctly again, so I close the problem for the moment that seems to have been solved.