@kisak-valve I've seen you changed the title but that's not what's happening at all 😅. As I wrote in the body it's not the Kraken X2 disappearing (which I should have specified is an AIO CPU cooler, while the Smart Device V2 is a fan/rgb controller) but my Xbox Series controller.
Can confirm the same issue on a system with a NZXT Kraken X, with PROTON_DISABLE_HIDRAW=1 being a workaround.
There was a great workaround posted in https://github.com/liquidctl/liquidctl/issues/860. SDL_GAMECONTROLLER_IGNORE_DEVICES=0x1e71/0x170e should solve the problem without disabling entire subsystems or multiple gamepad input like with the other workarounds in the thread. Perhaps this is targeted enough to make it in as a patch for Proton?
I also got the 1e71:170e NZXT Kraken and using SDL_GAMECONTROLLER_IGNORE_DEVICES=0x1e71/0x170e fixed all my controller issues.
Can confirm this exact issue, and I have a crash backtrace that may explain the mechanism.
1e71:170e) + ITE RGB LED controller (048d:5702), both with hidraw uaccess2dc8:310b and DInput 2dc8:6012 modes)All controllers work at kernel level (evtest), in native Linux games, and in the Steam client UI/controller test — but are completely invisible to every Proton game (games show keyboard prompts). Occurs with Steam Input enabled, disabled, and with PROTON_NO_STEAMINPUT=1. Persisted across a full OS reinstall.
Verified before finding the cause:
28de:11ff) is created, emits events in evtest, and is present in the container's /dev/input/run/udev/data inside the pressure-vessel container matches the host (all c13:* entries present)udevadm info on the virtual pad shows ID_INPUT_JOYSTICK=1, no ID_INPUT_IGNORESDL_GAMECONTROLLER_IGNORE_DEVICES in the game env does not include the virtual padWith PROTON_LOG=1 WINEDEBUG=+plugplay, enumeration errors on the Kraken:
00bc:err:hid:get_container_id_for_usb_udev_device Failed to get parent device.
00bc:trace:plugplay:enumerate_new_device Creating new device L"HID\\VID_1E71&PID_170E&MI_00\\512&57884173394&0&0&0".
...and shortly after, hidclass.sys crashes:
=>0 0x006fffff323a28 in hidclass.sys (+0x3a28) (0x000000018dfe90)
0x006fffff323a28 hidclass.sys+0x3a28: movq 0x40(%rax), %rsi
PE-Wine 6fffff300000- 6fffff30d000 Deferred winexinput.sys
PE-Wine 6fffff320000- 6fffff330000 COFF hidclass.sys
With the HID stack down, games enumerate zero gamepads — which would explain why the controller "disappears" for all Proton games while native applications are unaffected.
MODE="0600", TAG-="uaccess") restores controllers in all Proton games immediately — but breaks liquidctl for non-root usersSDL_GAMECONTROLLER_IGNORE_DEVICES=0x1e71/0x170e (as OP noted) is the cleaner option since liquidctl keeps workingFull PROTON_LOG attached.
ge-proton11-3x1 2026-08proton experimentalx1 2026-08proton hotfixx1 2026-08SDL_GAMECONTROLLER_IGNORE_DEVICES=0x1e71/0x170e`x4 2026-08PROTON_LOGx1 2026-08PROTON_LOG=1x1 2026-08PROTON_NO_STEAMINPUT=1`.x1 2026-08SDL_GAMECONTROLLER_IGNORE_DEVICESx1 2026-08WINEDEBUG=+plugplay`,x1 2026-08PROTON_DISABLE_HIDRAW=1`x2 2026-02PROTON_LOG=+hid`x1 2026-02
In order to control some devices on my machine, I have to apply the following two udev rules:
The first one does not alter proton behavior in any way, while the second makes my Xbox series controller (connected via usb) completely invisible to all games run via proton. Native Linux applications outside of proton are not affected.
I took the following screenshots from dolphin emulator run via proton, as it clearly shows all detected input devices. The controller effectively disappears after enabling the second udev rule.

Proton versions prior to 9.0-4 are not affected, while either
PROTON_DISABLE_HIDRAW=1orSDL_GAMECONTROLLER_IGNORE_DEVICES=0x1e71/0x170ecan be used as workaround on later versions.Here is a log generated with
PROTON_LOG=+hidof a game refusing to see my controller:steam-837470.log