Regression with PS5 controller behaviour since v5.13.12 release (erroneous inputs?)

[movisman]

Hi there,

Firstly, thanks for your hard work with the new kernel and all of the other major changes. It must have taken a lot of time and effort - like I said when responding to your update post on FB, these kind of 'under the hood' updates make a massive difference to MiSTer.

However, I believe I have discovered an issue with PS5 controller behaviour since the new kernel was released. I can replicate the issue easily and solve it by reverting back to the last release of the socfpga-4.19 kernel (210711) and MiSTer binary (210803).

Here are the details / process to replicate/solve:

1) PS5 controller is working well on previous kernel release (210711) and MiSTer binary (210803).

2) Update MiSTer to latest release (210825) and latest v5.13.12 kernel (210805).

3) As soon as the update is complete, the problems start - as follows:

• PS5 controller behaviour is erratic when using the analog sticks, a good example is Arkanoid. There is no smooth movement of the bat when moving the analog stick left and right, it jerks around and stops, etc. This is the same on any other game/core where you can use the analog stick (eg. Atari 5200).
• If you redefine the buttons using the global option on the MiSTer UI, since the update it will quickly skip past letting you define the 'right' dpad (it will flash up quickly and then go straight to defining 'left' - unless, you skip the 'stick 2 test: down' procedure (which precedes defining dpad 'right'). This then allows you to map the right dpad button.
• If you successfully define all your buttons, if you shake the controller on the menu screen it will move up and down. Same applies if you shake the controller when defining any buttons or directions, it will define a movement (I assume) to the action and move to the next button.

I'm not sure what's up but it looks like perhaps motion control is enabled, or something related to this is causing a ton of erroneous inputs perhaps? Not sure if there is more to it, but perhaps something related is responsible for causing all of the above issues. Maybe a previous fix was not ported across during the move to v5.13.12?

4) To solve the problem, simply downgrade MiSTer and the kernel back to the previous version - I used the MiSTer SD utility to reflash the '210711' kernel (latest 4.19) and MiSTer binary file '210803' on the same SD card.

5) Once complete, everything worked perfectly well again with the PS5 controller. No issues or random inputs, analog behaviour is good.

6) I update again to the latest kernel and MiSTer binary, and the problems start again. Exactly as step '3'.

7) Revert one more time back to 4.19, the problem is solved once again.

NOTE 1: This behaviour affects both USB and Bluetooth. NOTE 2: Unfortunately, I do not know if this issue also affects PS4 controllers, as I do not have one to test with.

I hope the above detail helps you to track the issue. If you require any testing I have 2xPS5 controllers and happy to assist if I can. I have a second SD card which I can test a different kernel with if you know what the problem might be.

Thanks!

[sorgelig]

it's because of motion sensors. I've removed exclusion in one place but forgot to add it to other place. This build should fix it: MiSTer.zip

[movisman]

Good morning,

Thanks so much 👍 The build posted above has fixed the problem!

Everything works fine. I have performed a full input test and checked several games, reconfigured the controller buttons, and no more erroneous inputs. I thought all of the issues were probably down to motion controls being enabled somewhere.

So actually it was only the MiSTer main binary which needed updating... no kernel files at all needed any work? That means i've filed this issue in the wrong place, I should have filed it in the Main_MiSTer repository rather than here - apologies. You can transfer it there if needed.

I should have tested just swapping the binary out for an older one rather than changing both main+kernel, although at the time though I figured the behaviour must be driver related, and thus related to the kernel. I didn't realise motion control behaviour was controlled within the main MiSTer binary. Something i've learnt today!

Thanks a lot for fixing it so quickly.

[sorgelig]

Before there was udev rule to remove motion input part of DS3/4/5. So it was a part of Linux. I removed this rule as i think it's not correct way and there are other gamepads with motion sensors which excluded in Main. So, correct way is to ignore these sub-devices in Main (which i've forgot to add).

[movisman]

Great, I understand and thanks for clarifying how it works. I thought it was some sort of rule previously, but wasn't sure how it was applied and if it should have been the same in the new kernel. Makes total sense excluding in Main instead, if that's where other gamepads with motion sensors are excluded. It works great now on the new kernel.

Thanks for fixing the functionality. I guess you'll roll this up into one of the next updates. Not sure if you want to keep this open until that's been done, or just close it off.

Thanks a lot for the help.

[sorgelig]

closing it as fixed.

[movisman]

Thank you Alexey.