protonscr

Steam Input no longer opens generic (evdev/DirectInput) gamepads after host udev 259 update — HIDAPI controllers still work

steamopen Distro Family: FedoraGeneral controller / Steam Input
ValveSoftware/steam-for-linux#13394 · opened 2026-07-07 by lig · updated 2026-07-07 · 0 comments · github
1 matching comments, n / p to jump
Llig 2026-07-07 github

Summary

After a routine Fedora system update, Steam Input stopped activating a generic USB gamepad (11ff:3331 "PC Game Controller"). Steam still enumerates the pad (Local Device Found) but never reaches Steam controller device opened for index 0 / Steam Controller reserving XInput slot 0, so no virtual controller is created.

Because Steam Input hides the physical device from games while providing no virtual replacement, the controller is dead in every game that uses Steam Input (and does not appear in the Controller settings list), even though the device, kernel drivers, SDL, /dev/uinput, permissions and SELinux are all verified working independently.

A native Sony DualSense (HIDAPI, USB) works fine via Steam Input on the same machine. Only the generic evdev/SDL-joystick path is affected.

System

  • OS: Fedora Linux 44 (Workstation Edition)
  • Kernel: 7.1.3-200.fc44.x86_64
  • Steam package: steam-1.0.0.86-1.fc44
  • Steam client build: 1783376539 (reproduced on stable, Steam Beta, and the experimental client)
  • systemd/udev: systemd-libs-259.7-1.fc44 — libudev.so.1.7.12
  • steam-devices-1.0.0.101^git20260611.bbf6cf0-2.fc44
  • Host SDL: 2.32.70; Steam-bundled SDL: 2.32.10 (scout) / 2.32.68 (pv-runtime)

Affected controller

  • USB ID: 11ff:3331 — "PC Game Controller" (generic DirectInput pad, no HIDAPI driver match)
  • SDL GUID: 03000420ff1100003133000010010000
  • 4 axes, 12 buttons, 1 hat

What works vs. what doesn't

Check Result
Kernel evdev / joystick / hidraw nodes OK (jstest: 4 axes, 12 buttons, 1 hat)
uaccess ACLs / udev tags on device + /dev/uinput OK
SELinux (Enforcing) Not blocking — zero relevant avc: denied; creating a /dev/uinput device (UI_DEV_CREATE) and SDL_GameControllerOpen both succeed as the normal user
System SDL 2.32.70 IsGameController=True, built-in mapping present, opens OK
Steam-bundled SDL 2.32.10 (run standalone) IsGameController=True, opens OK
Sony DualSense (HIDAPI, USB) via Steam Input Works
Generic pad 11ff:3331 via Steam Input Fails — enumerated but never opened/activated
Generic pad in-game with Steam Input disabled Works (game's own SDL reads the raw device)

Regression timeline

  • Last successful activation in controller.txt: 2026-06-23 21:49 (!! Steam controller device opened for index 0 / Steam Controller reserving XInput slot 0).
  • First broken session: 2026-06-30 23:11.
  • Fedora system update installed 2026-06-30 22:24–22:25 (~45 min earlier), including systemd/udev 259.7 and steam-devices-...git20260611.
  • The Steam client update (2026-06-19) is not the trigger — the pad still worked on 06-23, after that client update. Updating the client further (to 1782866176, 1783376539, Beta, experimental) does not fix it.

controller.txt — working vs broken (same device, same Interface: -1)

Working (through 2026-06-23):

Local Device Found
  type: 11ff 3331
  path: sdl://1
  Interface:    -1
!! Steam controller device opened for index 0.
Steam Controller reserving XInput slot 0
Controller PollState Changed from 0 to 1
SDL Mapping for 11ff/3331: 03000420ff1100003133000010010000,PC Game Controller,...

Broken (2026-06-30 onward, incl. current build):

Local Device Found
  type: 11ff 3331
  path: sdl://2
  Interface:    -1
Add to Config Cache Request 4294967295 769      <-- 4294967295 = (uint32)-1, controller never assigned a slot
Opted-in Controller Mask for AppId 0: 1005

The Opted-in Controller Mask was 1001 in both a working (06-23) and a broken (06-30) session, so this is not a Steam Input opt-in/setting change.

Additional environment notes

  • The Steam client and steamwebhelper run in a pressure-vessel container and load the host libudev (/run/host/usr/lib64/libudev.so.1.7.12) — i.e. this is not an old-bundled-libudev ABI issue; the current host libudev is in use and the generic path still fails.
  • HIDAPI controllers (hidraw path) are unaffected; only the generic evdev path regressed, which correlates with the udev 259.7 update.

Steps to reproduce

  1. Fedora 44 with systemd/udev 259.7 and a generic DirectInput USB gamepad (11ff:3331 here; likely any generic non-HIDAPI pad).
  2. Plug in the pad; confirm it works at OS level (jstest, and standalone SDL_GameControllerOpen).
  3. With Steam Input enabled, open Big Picture / a Steam-Input game.
  4. Observe: pad is enumerated (Local Device Found) but never opened; absent from Controller settings; non-functional in Steam-Input games.

Workaround

Disable Steam Input for the controller (per-game "Disable Steam Input", or globally). Games then read the raw device via their own SDL and it works — but Steam Input remapping is lost.

Diagnostic scripts used (attached / on request)

  • SDL_GameControllerOpen probe (ctypes → system and Steam-bundled libSDL2) — both report the pad as a working game controller.
  • /dev/uinput UI_DEV_CREATE test under the user's unconfined_t SELinux context — succeeds.

Launch options