Steam game doesn't pick the controller back after it was turned off.

[somewhatfrog]

Version of xpadneo

v0.9

Severity / Impact

mild but quality of life if playing online games where you get penalties for quitting during matches

Describe the bug

For instance, my batteries died and I needed to fast swap them for new ones and continue the match, but the game won pick up inputs even tho the xbox one controller is connected again. Particular game is Dark Souls 3. Also game doesn't pick the controller inputs if the controller was connected after the game was launched. I am sorry for taking your time if this is the the issue on the game side.

System information

Linux pop-os 5.8.0-7630-generic #32~1607010078~20.04~383a644-Ubuntu SMP Thu Dec 3 19:14:47 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

[kakra]

This is usually some problem in Wine, the driver cannot work around it. The cause for it may be that the Bluetooth connection timed out instead of disconnecting properly which can make Wine see the controller as a new one instead of the original one (the kernel will present the controller with a different ID in this case, and this is out of the scope of the driver) - the game may thus not pick it up correctly. But still, Wine should solve this.

Personally, I experienced similar problems in some games but not in others. So it may well be an issue with the game which does not tolerate switching to a "different" controller midst-game.

[kakra]

Probably a third party bug, see also here: https://github.com/ValveSoftware/Proton/issues/3291#issuecomment-750361965

[somewhatfrog]

Oh okay, thanks for clarification, I'll close the issue then.

[kakra]

I'll leave it open to have a reminder about it to write some notes in the documentation.

[orbea]

Personally, I experienced similar problems in some games but not in others.

Hot plugging works fine in wine when the game supports it, if the game doesn't support it then its a game bug.

Building wine against SDL2 might also help as its used for xinput.

[kakra]

Latest Proton (experimental) has a lot of improvements for gaming input hotplug: It seems Windows has a vast amount of different messages for announcing devices, and Proton/Wine did only implement a very limited subset of these. So that may explain why it didn't work.

Also, Proton has more complete SDL2 support than upstream Wine but yes: Compiling against SDL2 should be favored as it improves controller support and detection.

[ivyl]

Few notes on the Proton side: Starting form 5.13 up to 5.13-4 (exclusive) there was a regression caused by transition to the new container runtime and hotplugging didn't work at all, so make sure that you are updated here.

DS3 + XBox Series X controller (model 1914, recent build of xpadneo from master, not using Steam's controller mapping features) hotplugging works just fine with both 5.13-4 and the current experimental with my recent controller patches.

As of Windows APIs, there at at least three that the games seem to be using often for the controller handling: xinput, dinput and RawInput. Then on top of that you have different ways of telling that new device has appeared... Let me give you an example: official programming guide for xinput recommends just polling the disconnected controllers (controllers are identified by indices 0-3) periodically, e.g. every 2s, and most games do just that. But... there are a few more creative titles that are waiting on some external stimuli (particular window messages) or using a different API to do the discovery, like dinput, and then try to match the device path / params to tell if it should use xinput or stay with the other API.

So usually if the controller works at all, but hotplugging doesn't work with some games its probably those games being a bit too creative when it comes to controller discovery and that should be reported in the Proton's bug tracker.

[kakra]

@ivyl Thanks for the heads up. I found that primarily some older Ubisoft titles do not detect the controller at all (e.g., Far Cry Primal) or they detect it wrong (axis centers shifted or confused with analog triggers, e.g. Assassin Creed Unity and Black Flag). Do you know of any work-arounds for that or found a fix for it? In this example, AC:Unity used to work just fine with older Proton version (maybe 3.x or 4.x) tho it may not load at all with some specific Proton versions. So newer Proton versions would be preferred but apparently have these controller problems.

[ivyl]

Assassin's Creed Unity & Black Flag work for me with the newest experimental and the mapping looks fine, i.e. triggers have their own actions assigned and don't affect camera. FC Primal indeed doesn't pick up controller at all.

I have a few more input fixes queued up for Proton that need more polish and testing (the area is exceptionally brittle) and most likely will be in the next experimental. I'll check them with Primal and if that doesn't work I'll put in on my list of things too look at when I'm done with my current tasks.

If you want to look at those things yourself good place to start is to trace rawinput / dinput / setuapi / xinput calls and check how the values differ from what you would get on Windows. Getting traces from the game on Windows using dll hooking / API Monitor are often helpful.

[kakra]

@ivyl I can confirm that latest Proton Experimental (and probably some previous versions, I didn't test those games in a while) completely fixes AC:Unity and AC:Black Flag.

FC Primal still doesn't detect the controller despite my hacky work-around: https://github.com/ValveSoftware/Proton/issues/4579

So I found that some games simply use the first controller only they detect (e.g., Batman Arkham Knight) - and that was my HOTAS. Others seem to query just all controllers at once and that fires bogus axes values from the HOTAS (with the throttle being a camera axis). That may explain some more odd behavior. Excluding those from Proton for most games already fixes a lot of issues.

Maybe Proton xinput should only report controllers as gamepads that have the BTN_GAMEPAD in its evdev profile? It doesn't make sense to report ordinary joysticks as xinput devices: xinput is for 6-axis 10-buttons controllers only.

For FC Primal, it seems that it only works when the controller reports as the original Xbox 360 controller but I'm not sure if it compares by name or by VID/PID. I found several reports in different forums which seem to confirm that: People reported that it worked when the controller was connected via USB, others with non-original Xbox 360 controllers were successful with using x360ce to emulate their controller as a Xbox 360 wired controller. So these may be hints you may want to be looking into. I think with Proton being open source, and supporting more games already that even Windows 10 no longer supports, it's a perfect place to have some game-specific quirks to force some odd behavior on a per-game basis. Proton already does this in multiple places, so why not for input?

[kakra]

Latest Proton games should fix re-detection completely. If it doesn't work, it should be reported upstream to Proton for each particular game, it's most likely not an xpadneo issue if the controller was detected once but not later again within the game when re-attached.

Is the original report still an issue?

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.