Controller Issue without the `--no-bwrap` flag

[yacinbm]

Describe the bug I am trying to make my steering wheel (ThrustMaster T300RS) work with my Steam Deck and Proton 7 GE. The wheel does not respond in wine control joy.cpl without having the --no-bwrap flag.

To Reproduce Steps to reproduce the behavior:

1. Run command protontricks -c "wine control cpl" 244210
2. Under Test Joystick, move the steering wheel, and notice the buttons/movements are not detected.

Expected behavior When running protontricks -c "wine control cpl" 244210, wheel movements and button presses should cause a reaction in the Test Joystick tab.

System (please complete the following information):

• Distro: Steam OS 3.4.6 (Steam Deck Latest Stable)
• Protontricks installation method: Flatpack through Discover
• Protontricks version: protontricks (1.10.1)
• Steam version: Steam Deck Stable

Additional context I've been trying to track down an issue with my steering wheel in games using Proton versions > 5.13. The main game I am testing is Assetto Corsa on Proton GE 7.54. In AC's settings, I can see my steering wheel, but it does not respond to any movements/button presses. The steering wheel works as intended with native Linux tools such as evtest and oversteer show the wheel working as intended, pointing to a potential proton issue. While trying to track down my issue, I added a udev rule to ensure that all users/groups had r/w access to the device. I also tried running the wine control applet to check if the wheel was correctly recognized, which lead me to discover this behavior. The wheel responds to all inputs as expected, only when the --no-bwrap option is specified.

If the error happens when trying to run a Protontricks command, run the command again using the -v flag and copy the output! Verbose output

Side Note I realize you probably don't have access to a steering wheel or a Steam Deck for your local tests, but I believe this is an issue with permissions to the device within bubble wrap, or the steam runtime, as other users seem to have fixed this problem on other distros using the udev rule I mentioned. That being said, please let me know if I can give you any additional info, or if you have any idea to fix this. Cheers!

[Matoking]

When you say that other people have solved the issue using the udev rule, is the issue solved while launching the game through Steam using Proton?

One way to determine this is to launch the same command using Proton's own debug scripts. To do this, you can use the runtime configuration option in Proton instructions:

First, you can try running the command without Steam Runtime:

• Set the launch options for the game to PROTON_DUMP_DEBUG_COMMANDS=1 %command%. Launch the game once and close it.
• This should create a directory at /tmp/proton_STEAM_USERNAME, which contains an executable named run.
• Run the command like this: ./run control cpl (I'm assuming control is an executable you have installed separately from elsewhere. Adjust the path as necessary.)

Then, you can try running it again using the runtime:

• Find Steam Linux Runtime - Soldier in your Steam library.
• Open the installation directory by right-clicking the entry -> Properties -> Local files... -> Browse files.
• Open a terminal in this directory, and run ./run /tmp/proton_STEAM_USERNAME/run control cpl.

If the latter still causes the issue, it's likely an issue with Steam Linux Runtime. If not, Protontricks might be setting the runtime environment in a different way that causes it to fail.

You can try adjusting the configuration parameters for Steam Runtime in case something prevents it from working (use ./run --help to check what options are available). For example, you could try the following which should result in a "more permissive configuration" according to Steam Runtime:

$ ./run --devel /tmp/proton_STEAM_USERNAME/run control cpl

[yacinbm]

Hi @Matoking! First off, thanks for taking the time to write up this detailed answer and for your work in general on Protontricks.

When you say that other people have solved the issue using the udev rule, is the issue solved while launching the game through Steam using Proton?

Yes, exactly! Users in this thread have reported a similar issue, but they were able to fix it by adding the udev rule. However, I suspect that since I'm on a Deck, we don't have the exact same Steam environment.

First, you can try running the command without Steam Runtime

control is a wine applet you can run in order to list all joystick devices visible to your wine environment, and test their functionality. This meant that instead of passing the argument to the /tmp/proton_<username>/run I had to modify the last line of the script to run path/to/my/proton/wine64 control. By doing so, the applet opened up and worked as intended (all inputs function normally).

Then, you can try running it again using the runtime

As you suggested, Steam Runtime did indeed break the correct behavior. Upon running ./run /tmp/proton_<username>/run, the control applet opened but no inputs were detected.

I then proceeded to revert the changes I made to the run script and try to run the game without Steam Runtime to check if this was the root cause of my issue... and it was! I can't thank you enough for the info you gave in this post, I had no clue you could run games without the Steam Runtime environment.

Finally, do you know where I should report this issue? I have an open ticket on Valve's Proton Github page, would that be the right place?

TLDR The issue is with the Steam Runtime Soldier apparently!