Dualshock 4 v2 random timeout

[Invictaz]

Sometimes I can play 3 mins sometimes 10 mins.
With my Xbox Elite 2 I can play for 50+ mins and no problems.

It also has quite some weird behavior if you press the home button. It vibrates and changes color.

20240324_233647.mp4

20240324_233758.mp4

[Invictaz]

Maybe this is related to stopping when the DS4 is used?

PicoSwitch-WirelessGamepadAdapter/src/usb.c

Line 49 in 755fc8a

sleep_ms(5); // we need to sleep here to avoid starving bluepad core

[Invictaz]

I tried the legacy version and no problems there. Must be something down the road of the route where the submodule was created that errors began. I played for an hour with the legacy version on a Dualshock 4 v2 and no disconnection, no led changing and as a bonus the legacy version does seem to support my Wiimote Plus and fades slowly on pairing mode and stays on when connected.

In the other issue I posted my remapped version.

[juan518munoz]

I've experienced the same issue of random timeouts using a series X controller on v1.0.

Led changing is probably a leftover from the sample app this program is base from for the v1.0, it should be solved by just commenting a line of code.

[juan518munoz]

Sometimes I can play 3 mins sometimes 10 mins.
With my Xbox Elite 2 I can play for 50+ mins and no problems.

I believe that DS4 has gyroscopic reading, that makes bluepad reports pile up much faster, somewhere in there, a crash or starvation happens.

[Invictaz]

I don't really understand why the code was change so much. The legacy version supports much more controllers. I do understand the submodule but there was a lot of things changed.

From my belief the time-out happens sooner on the YouTube app of the Switch. Not sure if it is correct.

[johndoe3535]

@juan518munoz

Try to run usb on core 0 and bluepad32 on core 1.
The core 0 stack is limited to 4kb.
I think if the bluepad stack somewhere grows too large, it can bleed into the memory area of the usb core and lead to random crashes.

Memmap default contains the alignment of the different memory areas
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_standard_link/memmap_default.ld
https://forums.raspberrypi.com/viewtopic.php?t=335833

[Invictaz]

@johndoe3535 A good thought but why does this not happen in the legacy version? As long as Bluetooth traffic was not sniffed how can we know it is the reports piling up?

[juan518munoz]

@johndoe3535

Wasn't aware of the stack limitations on the core 0, I will check if this makes a change. Thanks!

[Invictaz]

@johndoe3535 the USB side isn't crashing. The controller still stays connected but starts doing weird inputs in racing games (e.g. sudden fully locked steering to the right). I have the same behavior on a Windows98 machine and a Dualshock 4 adapter by Sony. It believe it to be a memory problem. I have too much memory in that Windows 98 machine. Other than that I don't know.

[juan518munoz]

I've updated the codebase to switch cores between the usb and bluepad task. @Invictaz please compile and check if the DS4 issues persist on the latest commit.

[Invictaz]

When you close issues and ask users to do compiling and testing your code you are losing goodwill to submit new bugs and ideas. As the legacy version supports more controllers, works fine and there is no explanation why fewer controllers are supported on the newer version (apart from the need to have Bluepad as an easier to update submodule) it's still unclear to me which direction this code goes.

For example the new Bluepad 4.0 is interesting to include (bump version) but apart from that there is almost no reason.

Having multiple controllers available is preferable to me than the timeouts. And of course the Switch Pro output descriptors.

I see what I can do in the coming days.

[juan518munoz]

When you close issues and ask users to do compiling and testing your code you are losing goodwill to submit new bugs and ideas.

Issues related to bugs are left open (like this one) until solved, the other issues were closed as they are beyond the current scope of the development of this application, I assume that anyone who is willing to implement this features will do so for self benefit and not because it's suggested by someone else.

As the legacy version supports more controllers, works fine and there is no explanation why fewer controllers are supported on the newer version (apart from the need to have Bluepad as an easier to update submodule) it's still unclear to me which direction this code goes.

This is an error on my side and will address it as soon as I can. Bluepad's submodule implementation makes the codebase much more coherent and easier to update, it's more of a backend change rather than a user experience feature. Having only a series X controller to test with, I wrongly assumed that this changes wouldn't break other controllers, but now I see they do. I'll revert back the main branch to a more stable commit, and leave the newer implementation on a separate develop branch.

ask users to do compiling and testing your code

Please be reminded that this repository is an open source project aimed towards collaborative work. I don't own any controller aside from an Xbox one, and neither make a living out of this, so the time and resources I can dedicate to the project are not much.

[Invictaz]

When you close issues and ask users to do compiling and testing your code you are losing goodwill to submit new bugs and ideas.

Issues related to bugs are left open (like this one) until solved, the other issues were closed as they are beyond the current scope of the development of this application, I assume that anyone who is willing to implement this features will do so for self benefit and not because it's suggested by someone else.

As the legacy version supports more controllers, works fine and there is no explanation why fewer controllers are supported on the newer version (apart from the need to have Bluepad as an easier to update submodule) it's still unclear to me which direction this code goes.

This is an error on my side and will address it as soon as I can. Bluepad's submodule implementation makes the codebase much more coherent and easier to update, it's more of a backend change rather than a user experience feature. Having only a series X controller to test with, I wrongly assumed that this changes wouldn't break other controllers, but now I see they do. I'll revert back the main branch to a more stable commit, and leave the newer implementation on a separate develop branch.

ask users to do compiling and testing your code

Please be reminded that this repository is an open source project aimed towards collaborative work. I don't own any controller aside from an Xbox one, and neither make a living out of this, so the time and resources I can dedicate to the project are not much.

I don't necessarily agree. Having an adapter output to multiple consoles benefits the whole (retro) gaming community and simply there is no alternative as HID-Remapper and others do not do PS3 output. OGX-Mini does but not as a Dualshock 3 yet so it doesn't work foolproof and it has no bluetooth input. Bluepad32 has no fork that does output to other consoles.

From my limited code experience the legacy github codebase was for an unexperienced coder like me much easier to understand and easier to find in several directories what goes where. The new codebase is spread all over the place. There must be any good reason for it to change the main c plus plus file. As for now, I can invest quite some time experimenting but only with the "old" code. I don't understand enough of the new development. So when I might write changes to a fork you might have to transplant them to your new development branch and make adjustments. That's the only thing I can do.

I do however have all kinds of controllers so I can test, submit debug logs and extract HID behavior whatever you want. Only the more obscure controllers like Astro, Stadia or Switch Online I don't have. But for the rest I have most of them.