Hello @dlorencic, this reads more like a kernel issue than a Proton issue. Since it's between hid_asus and Steam Input, I've transferred this issue report to the steam-for-linux issue tracker for a Steam Input dev to ponder. It might be worthwhile to also mention your findings to the maintainer(s) of the hid_asus kernel module.
Reproducing the same underlying symptom — Steam's virtual Xbox 360 pad (uinput) being torn down and recreated mid-session — on completely different hardware, which suggests this isn't specific to the hid_asus brightness/volume-key trigger described above.
System: Bazzite (Fedora Atomic) desktop, AMD GPU (RADV), kernel 7.2.0-ogc4.1.fc44.x86_64. Controller is Valve's own wireless "Steam Controller 2026" (Puck dongle, 28de:1304), not a third-party pad. No ASUS hardware, no brightness/volume key presses involved.
Observed:
$ journalctl -k | grep "X-Box 360 pad 0"
Aug 22 21:54:29 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input47
Aug 22 21:56:19 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input49
input47 was destroyed and replaced by a new virtual device (input49) less than 2 minutes into the session, with no keyboard/media-key input involved. ~/.local/share/Steam/logs/controller.txt logs the same moment as a mapping change:
[2026-08-22 21:56:19] Controller 0 mapping uses xinput : false
(having reported Controller 0 uses xinput : true several times in the preceding 90 seconds).
Right before the recreate, controller.txt shows Steam itself cycling through several different apps' controller configs in quick succession (Queueing activation for controller: 0 app: 2163330, then 443510, then 413080, then 2163330 again — all within the same ~20 second window, apparently from Big Picture/library navigation, not gameplay). That's a different trigger shape than the ASUS brightness-key case above, but the same underlying failure: the virtual pad gets rebuilt for reasons unrelated to the physical controller doing anything.
Separately (and I can't confirm this is the same bug, just noting it since it happened in the same session): steamwebhelper segfaulted (SIGSEGV) about 4.5 minutes after the uinput recreate event, stack trace fully inside stripped steamclient.so with no usable symbols. Steam auto-restarted and recovered on its own; minidump should have been auto-uploaded via the built-in crash reporter. Flagging in case it's a downstream effect of the same instability rather than coincidence, but I don't have direct evidence linking the two.
Happy to grab more logs/gists if useful — this reproduced on a system with no ASUS components at all, so the trigger surface for the underlying uinput-recreate bug looks broader than currently scoped.
Follow-up with a cleaner isolation of this, since I initially chased two wrong leads (game-side anti-cheat stalls, then a Steam Input "native API vs XInput emulation" theory) before landing here.
Game: Warhammer 40,000: Space Marine 2 (appid 2183900). Controller (the Puck) has never worked in this game at all, from the very first launch of any session - only the Steam-button chord (handled by the Steam client itself, outside the game's input path) responds.
Ruled out:
journalctl -k and controller.txt that the Puck's dongle link stays connected the entire session, no disconnect events logged.mapping uses xinput : false) - see below, this is now conclusively ruled out.Key isolating test: paired a completely different, generic Bluetooth gamepad and tried the same game. It works correctly. Checked controller.txt for that session and the generic pad is also managed through Steam Input, registered as its own controller slot, and also shows Controller N mapping uses xinput : false - the identical setting the (non-working) Puck has. Since a controller with that exact setting works fine, xinput: false was never the actual problem.
The real difference: the Puck goes through Steam's own proprietary wireless dongle pairing/registration protocol on every connect (WIRELESS SYSTEM DEBUG, BYieldingRegisterSteamController, BYieldingCompleteSteamControllerRegistration) - plumbing a standard Bluetooth gamepad never touches at all, since it just enumerates as a normal kernel Bluetooth HID joystick. That Puck-specific wireless re-registration cycle is what correlates with the uinput virtual-device churn from my first comment here (12 recreates in 13 minutes, input71 through input82). So this looks like it's specifically about how the Steam client manages the Puck's wireless dongle session for some games (still don't know what differs between "affected" and "unaffected" games), not a general Steam Input problem and not this particular game's own controller-reading code - a real Bluetooth-native pad sharing the exact same Steam Input config works fine in the same title.
Further generalizing this: the churn reproduces with no game running at all - just sitting in Big Picture/Steam's own UI. Checked just now with every game closed (ps aux confirms nothing but the Steam client itself running):
Aug 24 23:03:08 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input96
Aug 24 23:03:13 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input97
Aug 24 23:04:21 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input98
Aug 24 23:09:17 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input99
Aug 24 23:09:26 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input100
Combined with the earlier finding (a generic Bluetooth gamepad, sharing the identical Steam Input config/settings, doesn't hit this at all), this looks like a straightforward Steam client / Puck wireless-dongle bug with no game involvement required to reproduce - just Big Picture idling.
One more thing noticed but not confirmed as connected: around the same general timeframe, controller.txt shows a large batch of heavily-delayed CVibrationWorkItem/CImpulseTriggerWorkItem entries (queued 150-175ms) ending in Exiting workitem thread. Flagging in case it's a useful lead for someone who can see the actual code, but I don't have solid evidence it's the same event as a specific recreate rather than routine thread-pool housekeeping - not asserting a causal link, just noting it was there.
proton 10.33x1 2026-03SDL_JOYSTICK_ALLOW_BACKGROUND_EVENTS=1`x1 2026-03
Compatibility Report
System Information
I confirm:
Symptoms
When pressing brightness keys and sometimes volume keys on the built-in keyboard of an ASUS ROG Flow Z13 (GZ302EA, 2025)
during gameplay, the gamepad stops responding entirely. The game must be restarted to recover. This affects all tested controllers (8Bitdo SN30 Pro via USB and
Bluetooth, Xbox controller) with both Steam Input enabled and disabled.
The root cause appears to be that Steam's virtual Xbox 360 pad (created via
uinput) is torndown and recreated excessively throughout the session — over 40 times in a single session was
observed. When this happens during gameplay, modern AAA games lose the controller and do not
recover. The physical controller never disconnects; only Steam's virtual device cycles.
The issue is exclusive to the built-in ASUS keyboard. An external keyboard pressing the same
keycodes does not trigger the drop. This points to the
hid_asusdriver doing additionalprocessing (unmapped vendor HID usage page codes
0xec/0x9e) that disrupts the uinputvirtual device layer.
Older/indie games (Left 4 Dead 2, 7 Days to Die, Huntdown) are unaffected, consistent with
modern AAA engines explicitly handling
WM_ACTIVATEAPP(FALSE)by releasing all input deviceswithout re-acquiring them.
dmesg excerpt showing virtual device cycling:
Reproduction
What was ruled out:
SDL_JOYSTICK_ALLOW_BACKGROUND_EVENTS=1launch option (no effect)Related Bazzite issue (hardware-specific root cause):
https://github.com/ublue-os/bazzite/issues/4458