protonscr

Exo One

protonopen appid 773370Game compatibility - Unofficial
ValveSoftware/Proton#9989 · opened 2026-07-19 by ICBSupport · updated 2026-07-19 · 2 comments · github · game page · search this game
IICBSupport 2026-07-19 github

Compatibility Report

  • Name of the game with compatibility issues: Exo One
  • Steam AppID of the game: 773370

System Information

  • GPU: AMD Radeon RX 9070 XT (Navi 48)
  • Video driver version: Mesa 26.1.5
  • Kernel version: 7.1.3-2-cachyos
  • Link to full system information report as Gist LINK
  • Proton version: Proton Experimental (July 2026); also proton-cachyos 11.0.20260702.
    Not present in proton-cachyos 11.0.20260602 (worked 2026-07-17, broke after upgrading).

I confirm:

  • [x] that I haven't found an existing compatibility report for this game.
  • [x] that I have checked whether there are updates for my system available.

Symptoms

Xbox Wireless Controller over Bluetooth (045E:02E0, kernel hid-microsoft driver) is not detected in-game when Steam Input is disabled for the game. Steam itself detects the controller and its button test works. The game shows no error it simply sees no controller.

THIS LIKELY AFFECTS any game with Steam Input disabled and this pad, not just Exo One! I tired it on a different game that steam input disabled and same issue!

Root cause: current Proton opens Xbox BT pads via /dev/hidraw*, but steam-devices udev rules have no hidraw access entry for 045E:02E0 (unlike Sony/Nintendo pads and the Xbox Elite 2), so the node is root-only. The PROTON_LOG shows winebus/winexinput enumerate the pad but plugplay fails to open it with exactly one error in the log:

    err:plugplay:enumerate_new_device Failed to create or open device
    L"HID\\VID_045E&PID_02E0&XI_00\\2307&0000ffffffff02e0045e&0&0&1", error 0xe000020b.

setfacl -m u:$USER:rw /dev/hidrawN on the controller's node makes it appear in-game immediately with no other change. A permanent udev rule (KERNEL=="hidraw*", KERNELS=="*045E:02E0*", MODE="0660", TAG+="uaccess") fixes it across reboots. Filed steam-devices ISSUE requesting that rule.

Older Proton handled this same configuration fine (presumably via evdev, which does get a uaccess ACL).

I think when a hidraw node exists but is unreadable, it should fall back to evdev or log a warning I kept on thinking it was the game until I tried others.

Both logs attached: steam-773370-broken.log (no hidraw access, contains the error) and steam-773370-working.log (with udev rule, no error).

Reproduction

  1. Pair an Xbox Wireless Controller (045E:02E0) over Bluetooth on a system whose steam-devices rules lack a hidraw rule for it (current steam-devices 1.0.0.86).
  2. Disable Steam Input for the game (Properties > Controller > Disable Steam Input).
  3. Launch on Proton Experimental. Controller is not detected in-game.
  4. setfacl -m u:$USER:rw /dev/hidrawN on the controller's hidraw node, relaunch controller works.

I did a personal fix with the following for future reference:

echo 'KERNEL=="hidraw*", KERNELS=="*045E:02E0*", MODE="0660", TAG+="uaccess"' | sudo tee /etc/udev/rules.d/71-xbox-bt-hidraw.rules
sudo udevadm control --reload

steam-773370-broken.log
steam-773370-working.log

Kkisak-valve maintainer 2026-07-19 github

Hello @ICBSupport, you've already identified your issue is with device permissions, so I don't see the point in this issue report.

Closing as a duplicate of https://github.com/ValveSoftware/steam-devices/issues/89.

IICBSupport 2026-07-19 github

Because it happened due to a proton change, it's a proton issue about a device issue. Shouldn't the other one be closed instead?

Proton versions

Launch options