Blasphemous - mapping seems wrong.

[CaptainCoward]

Version of xpadneo

0.9.7

Controller Model

• [ ] Xbox One S controller
• [ ] Xbox Elite 2 controller
• [x] Xbox Series X|S controller
• [ ] Other:

Connection mode

• [x] Bluetooth connection
• [ ] USB cable (not yet supported)
• [ ] Xbox Dongle connection (not yet supported)

Installed Software

• [ ] Anti-Micro (may affect button mappings)
• [ ] OpenRGB (may mess up mappings and rumble stability)
• [x] Steam Input (enabled by default via Steam Desktop client)
• [ ] Steam Link (usually via Raspberry Pi or other micro computers)
• [ ] devices with QMK firmware (may affect udev rules, similar to OpenRGB)
• [ ] netstick (shares input devices via network similar to Steam Link)
• [ ] xboxdrv (user-space gamepad driver)
• [ ] xone (kernel-space gamepad driver using the Xbox dongle or USB)
• [ ] xow (alternative driver using the Xbox dongle)

Protocol Information

Please help us identify at which layer the problem can be found if you want to report mapping errors or if the controller fails to be detected:

• [ ] Steam Proton games are having issues
• [x] Steam Linux-native games are having issues
  • [ ] I don't use Steam or did not try
• [ ] games running through Lutris, wine and/or Bottles are having issues
  • [ ] I don't use Lutris, Bottles, wine or did not try
• [x] Linux-native games are having issues
  • [ ] I don't use native games or did not try
• [ ] Other software is having issues (describe software and issues below)
• [ ] Running evtest is showing issues (describe the issues below)
  • Keep in mind that BTN_NORTH and BTN_WEST are intentionally swapped
• [ ] Running jstest is showing issues (describe the issues below)
  • [x] I don't have this tool or don't know how to use it
• [ ] Running gamepad-tool is showing issues (post console output below)
  • [x] I don't have this tool

Please describe how it is failing below in the next sections.

Severity / Impact

• [x] I've read the docs and the bug reporting instructions
• [ ] I've applied the latest firmware update to the controller
• [x] I've tried disabling or running without above mentioned software
• [ ] It does not work at all
• [ ] It used to work in a previous version
• [ ] It mostly works but sometimes it doesn't
• [ ] I found a work-around
• [x] I probably didn't figure it all out but it's too early to give up
• [ ] I don't know how to ...
• [ ] It's too complicated
• [ ] Fantastic work but ...
• [ ] I can code and I want to help

Describe the Bug

Don't know if this is worth a report or if this is somewhat to expected:

When running the game native without enabling the steaminput (which is off by default for the game) the mapping appears to be odd. Some buttons for example the L and R Triggers will get mapped to the right analogstick while the directions of the right analogstick are wrong as well. Currently the only fix seems to be using steaminput. I don't know if the gog version also suffers from this issue.

Steps to Reproduce

Just run the game natively and try to map the buttons

[kakra]

This is a known issue with some older native games which expect a DirectInput gamepad. This affects almost all native Unity games because Unity uses a completely wrong internal mapping. I've installed Unity and tried the demos that came with it, and it was just plain wrong. I think the problem is that it may be using the joydev driver in Linux which doesn't really have consistent mapping.

You can probably use our jscal example to correct for that. I don't think Steam Input makes any difference here because it doesn't handle joydev devices, it uses evdev and it supposed to be used with SDL by games.

The worst implementations are those which use evdev to infer an axis and button mapping but then use joydev to actually read the input. Chrome is one such example (obviously, Unity is another, and a lot of Java games do the same silly stuff). Such software will become completely clueless if you use the following fixups.

Here's a starting point:

• https://github.com/atar-axis/xpadneo/blob/master/docs/TROUBLESHOOTING.md#gamepad-axes-are-swapped-seemingly-unresponsive-or-strange-behavior
• https://github.com/atar-axis/xpadneo/blob/master/misc/examples/udev-rules/99-xpadneo-joydev.rules

The most proper fix is most likely to not use the native version of the game.

If the jscal trick works for you, you could still create a wrapper script to run the game (e.g., fix-joydev %command%), and that script would first store your current joydev configuration, then set it how the game expects it, start the game, and after quitting the game, it could restore the configuration to not mess up Chrome or other software using joydev.

If you want to make your script handle different games, you can look at the Steam ID environment variable to know which game is to be run. I don't recall how the variable is called exactly, the Proton python script to run games should reveal it because it uses a similar trick to setup workarounds.

You should install the jscal and jstest tools to analyze and work around this issue, or just use the native version of the game which will most likely perform better anyways. Just enable and select the Proton compat layer in the game properties so Steam doesn't default to the native version.