protonscr

Proton possibly not correctly presenting OS HID inputs to the application software

protonopen
ValveSoftware/Proton#9408 · opened 2026-01-18 by nrrdzilla · updated 2026-03-16 · 4 comments · github
2 matching comments, n / p to jump
Nnrrdzilla 2026-01-18 github

Your system information

  • Steam client version (build number or date): Mon, Dec 22 4:48 PM UTC -08:00
  • Distribution (e.g. Ubuntu): Nobara (Fedora derivative)
  • Opted into Steam client beta?: No
  • Have you checked for system updates?: Yes
  • Steam Logs: This issue generates no logs in the sense that you mean, AFAIK.
  • GPU: Nvidia

Please describe your issue in as much detail as possible:

This revolves around USB (or BT, I guess) device enumeration at the system level, and then how (I think) Proton is presenting this information to applications. This has been tested with two different flight sim controllers, against 3 different Steam FPV drone-sim apps:
FPV.SkyDive
LiftOff
UFDS (Ukrainian Fight Drone Simulator)

The two controllers are:
RadioMaster Pocket ELRS (tested when connected both as USB and as BT)
BETAFPV LiteRadio 2 SIM Controller (wired-only controller by USB)

Both controllers work flawlessly with all 3 apps (tho it's been some time since I last opened FPV.SkyDive) on Win11, being detected and presented to the apps in (what I assume is) the expected way, and thereby allowing the user to configure and calibrate them as desired. When looking at SETTINGS --> CONTROLS in UFDS, verify that the controller has been properly detected, and that the relation between the sticks and the expected axes (and direction therein) are as desired.

On Linux using Proton, the only of these 3 apps that is usable, and connects to the controllers correctly, is LiftOff. Both the other apps exhibit the same issue, in that the controller is not correctly recognized, and therefore cannot be configured or calibrated.

The attached document shows:
Page 1: connection and enumeration of the RadioMaster controller, as reported in Win11
Page 2: connection and enumeration of the BETAFPV controller, as reported in Win11
Page 3: three states (separated into blocks of text) of connection and enumeration of, in order: no controller connected, BETAFPV controller connected (identified as USB ID 0483:5750 ), RadioMaster controller connected (identified as USB ID 1209:4F54)

device management logs.txt

If importing this document into a word processor, please set the typeface to something monospace, to make the columns readable.

Steps for reproducing this issue:

  1. Plug either of these controllers into the host computer USB port.
  2. Verify that the controller has been detected and enumerated.
  3. Start up UFDS, and once the opening screen showing drone animations has appeared, clock on SETTINGS, which will in all likelihood come up in "GAMEPAD" mode, instead of "CONTROLLER".
  4. Verify that the only allowed input selections are KEYBOARD and GAMEPAD, that the joystick and switch mapping are mixed up, and that there are no configuration options available under GAMEPAD. CONTROLLER will show as greyed-out.

Similar behaviour should emerge when running FPV.SkyDive with either of these two controllers.

My feeling is, given that UFDS is a windows app running inside Proton, it relies on Proton to present the controller hardware to the app, in a generic fashion that is close to (if not nearly identical) to what the app would experience running natively on Win11. If the two controllers have been somehow detected and used outside of that aforementioned, by LiftOff, there's something different being done by LiftOff which results in the controller showing the user proper connection notifications, and allowing (re)configuration of the axes and buttons under Options --> Controls --> Controller

Please feel free to contact me for more information.

Nnrrdzilla 2026-01-18 github

I just wanted to toss an extra thought on to the heap:

The BETAFPV USB flight controller lists for something like $19USD, and shipping from China to Canada took about a week. Resellers in the continental US may even stock them, though I couldn't find any stock in Canada.

I'm guessing this tiny outlay for testing hardware is worthwhile and falls inside the QA testing dept budget ;)
(subtle, no?)

Ttbelvin 2026-03-08 github

I also have trouble getting my controller to be recognized correctly with UFDS when using any release of Proton. My TX16S is recognized by the game, but the control sticks don't move correctly.

Unrelated, but I also have to launch with PROTON_HIDE_NVIDIA_GPU=1 %command%

Ttbelvin 2026-03-11 github

Got TX16S controller working in this game with Proton, but it took extra steps.

  1. Only Proton version 10.0-4 so far.
  2. Launch options: PROTON_ENABLE_HIDRAW=0x1209/0x4f54 SDL_JOYSTICK_HIAPI=0 PROTON_HIDE_NVIDIA_GPU=1 %command%
  3. Add udev rules for controller.
  4. Make registry changes in wineprefix with Protontricks:
    "Enable SDL" = 0, and "Map Controllers" = 0.

Various websites will explain the details after searching.

It's worked before with a different old version of Proton, and then stopped working after possibly a game update or a minor change.

The working axis setup for the control sticks in the game will need to be changed from the almost working versions in different releases of Proton.

Trying to map the controllers sticks to Steam gamepad instead will add dead zones that can't be removed.

Ttbelvin 2026-03-16 github

I made an entry into ProtonDB which should help some Linux users. https://www.protondb.com/app/2862860