Possible problem with linking multiple /dev/input devices together for PS5 controller #16
Comments
|
Thanks for the very detailed report, that's highly appreciated! You went down the rabbit hole uh? If you're interested in what lies below that SDL call I've written a bit of rationale behind the matching in SDL in here. My guess is that AntiMicroX is linked to an old SDL version for some reason, can you double-check that? Also, is it running in the host or is it via Flatpak or some container like that? As a side note, to better test SDL + joypads I've forked a little CLI utility that you can easily compile and test: https://github.com/games-on-whales/sdl-jstest you can run it with |
|
Way down the rabbit hole yes lmao. AntiMicroX reports it's using SDL version 2.30.7 in its logs. All apps running native on OpenSUSE Tumbleweed. Another thing to note is that Steam is able to pick up the gyro, and it works flawlessly through steam input, but Steam may be unifying the inputs in some other way. I was able hack around what I was trying to do by using the virtual controller steam-input creates, so I don't necessarily need a fix here, but figured it's worth surfacing at least. I'll see if I can give |
|
Right, so that's the very latest SDL2 fresh from release. I can try upgrading my local installation and see if I can reproduce the issue (I'm currently at 2.30.0). If you could give |
|
Alright, yep. Confirmed same behavior in |
|
Thanks for confirming, I'll test out the latest SDL version on my end too. If that still works on my side I'm afraid it'll be some permission issue with the udev rules.. |
Noticed a very strange problem that I think I've narrowed down to here (though could be wrong as there are a few moving pieces in this setup, but I'll explain why I think this library is the root cause). I'm using Sunshine for game streaming, which creates an emulated PS5 controller for motion control through this library. As far as I can tell, Sunshine appears to be using this library correctly (and very simply). An emulated controller is created as expected, however some applications are not able to link the multiple eventX devices back together.
I noticed the problem using an application AntiMicroX to map controller inputs to keyboard events. AntiMicroX would show a gyro section in its UI when a native PS5 controller was connected directly to my machine, but that field was missing from the emulated PS5 controller from Sunshine (created with inputtino). Using
evtest, I'm able to see the "... Motion Sensors" /dev/input/eventx item for the emulated controller, so it definitely exists, and the "... Motion Sensors" input does respond to gyro changes from the device inevtest(since the device inputs do exist, that implies Sunshine is likely not the root cause)Next I dug into AntiMicroX's code, and what I ultimately found, by building AntiMicroX from source and attaching a debugger, was that
SDL_GameControllerHasSensor(referenced usage here) errors for every availableSDL_SENSOR_<TYPE>, which would imply that SDL is not actually able to unify the sensors back to the primary controller. (Because I've now traced this issue down to native SDL library calls failing, that implies AntiMicroX is likely not the culprit)Now again, I know there are a bunch of moving pieces here in my particular setup. I haven't attempted to reproduce this outside the context of this setup, but I suspect if I did I may run into the same issue. AntiMicroX is just making a few SDL_ library calls, Sunshine is just making a call straight to inputtino to create the controller, and I find it unlikely the bug originates from SDL itself, which leaves inputtino as the only piece left in the chain.
I would try to create a small cpp app to reproduce, but I already spent too much time tracing the issue and don't really have more time to dedicate to it LOL. Happy to bring this over to one of the other projects mentioned if you're not able to reproduce and think one of them may actually be the root cause.
The text was updated successfully, but these errors were encountered: