Rumble stops working in Proton Games with v0.9-44

[DarthShredder]

Version of xpadneo

affected v0.9-44 not affected v0.9-36

Severity / Impact

• [ x ] It used to work in a previous version
• [ x ] I found a work-around

Describe the bug

I updated to v0.9-44 and the Rumble feature with Xbox One Controller stops working on Proton emulated Games like Rocket League, Project Cars 2 etc. Linux-Native Games like BallasticNG are not affected. If I use the previous version v0.9-36 that I have from backup it works fine with Proton and Linux-Native Games

Steps to Reproduce

Update xpadneo to latest v0.9-44 and start a Windows Game from Steam with Proton 5.13 where Rumble is used

uname -a

Linux 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux

[kakra]

Please try with SDL_JOYSTICK_HIDAPI=0 when starting the game and report back.

[kakra]

Also, the rumble may stop on low battery levels. Does it still run the connect rumble?

[DarthShredder]

Thank you for the ideas! When I use the Controller via usb also Rumble works. Battery Level seems not the Problem. Bluetooth seems the problem at all. I tried also "SDL_JOYSTICK_HIDAPI=0 %command%" as Launchoption in Steam and Rumble also works with Bluetooth.

Solution at the moment "disable joystick hidapi global or use usb attached".

[kakra]

The USB driver is different, it's not using xpadneo then. And when connected to USB, the battery doesn't matter.

If you pinpoint Bluetooth, another problem may be disabled ERTM. Tests showed that rumble is unreliable with ERTM disabled. Apparently, the controller most likely won't pair or connect when ERTM is enabled and you do not use the L2CAP patch in the kernel (will be in kernel 5.12).

If I understand you correctly, using SDL_JOYSTICK_HIDAPI=0 makes the controller rumble again? In that case it's not a problem with Bluetooth but with SDL2 itself: In HIDAPI mode ( =1 or unset), it is allowed to bypass Linux input drivers and directly read raw HID reports. It may simply not implement rumble in that mode (because it doesn't fully detect the model or your model is not whitelisted). The HIDAPI patches in SDL2 are also lacking the rumble bug workaround.

Conclusion: If the controller doesn't rumble at all, it's probably a problem in SDL2, if it rumbles a few times but then eventually stops at some point, it's probably a Bluetooth problem (ERTM, L2CAP).

[DarthShredder]

I think you are right but when I use the old version there is no problem I have no idea of course, but it seems like it is maybe related to the disable-ff ( https://github.com/atar-axis/xpadneo/commit/5be4cb1fcb39e8c2177b530f5b11c23fcaf98ef2 ).

Indeed I have no problem now to use the older version or to set SDL_JOYSTICK_HIDAPI=0 globally.

In any case many thanks for your help

[kakra]

I have no idea of course, but it seems like it is maybe related to the disable-ff

No, the problem is that we fixed udev to properly initialize the driver at the right rules position which enables write access to the rawhid device for the current seat user (that is you, the user who currently views the graphical desktop), which in turn can be successfully used by SDL2 HIDAPI then: https://github.com/atar-axis/xpadneo/commit/eee6d5b8f6ca9b022267cadd2c477e2a0d9660e3

The disable-ff parameter was dead anyways. That commit was purely a cleanup commit, reflecting a previous older change back into the configure script.

So in the end, the problem is that your distribution enabled HIDAPI in SDL2 but SDL2 doesn't have proper full support for all controllers yet (or misidentifies the supported models). In theory, HIDAPI will give you lower input latency because input handling doesn't need to pass through the rather complex kernel processing for that, and instead SDL2 can directly read reports and pass them to the game completely in user space. It is also supposed to support controllers which have no working driver in the kernel, but that brings us to the point that in this case SDL2 cannot know how to rumble the controller.

Last time I looked at the SDL2 source code, it seemed that it would not even try to use HIDAPI for Xbox controllers (on Linux at least). Things may have changed since then. If they did, SDL2 probably also needs the rumble frequency work-around to not crash Xbox controllers.

Note: With latest Steam runtime, the "distribution which enabled HIDAPI" may well be the Steam runtime itself.

[DarthShredder]

I understand it thanks to your good explanation Thanks a lot! I think we can close the issue then

[kakra]

No, it will be closed by an update to the documentation.