Confirmed live: Steam's own controller detection and test screen worked
fine (device listed, buttons fired correctly, Gamepad template applied)
but every actual game — a real Steam title or a non-Steam emulator
shortcut alike — saw no controller at all.
Root cause: Steam Input never hands a game the raw controller device.
It exclusively grabs the raw device for itself and creates its own
synthetic virtual controller via /dev/uinput, then hands that synthetic
device to the game. Reading/testing the raw device (what Steam's own
controller page does) doesn't need uinput; creating the virtual output
device it hands to games does. The 'steam' CATALOG entry only granted
/dev/input/*, /dev/dri/*, /dev/nvidia* via GOW_REQUIRED_DEVICES and had
no devices= list at all — so Steam Input could read the controller but
could never create the virtual device games actually see.
This is the exact same requirement the 'esde' entry already has for
AntiMicroX (also a uinput-based synthetic input tool), including the
same two-part fix noted in its own comment: GOW_REQUIRED_DEVICES alone
only gets the base image's entrypoint script to bind-mount the node —
the container also needs Wolf's own create-time devices= grant to
actually open it. Added /dev/uinput to GOW_REQUIRED_DEVICES and a
devices=['/dev/uinput:/dev/uinput'] entry to both copies of the
'steam' CATALOG dict, matching esde's existing pattern exactly.
update_field() already refreshes an existing app's 'devices' field on
rerun (added specifically for this same esde/AntiMicroX case per its
own comment), so reselecting Steam via 'sudo ./setup.sh wolf' or
'./manage.sh apps' picks this up without a fresh reinstall.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013BWYKEERLA1a7gv86Z4W23
Claude
9524c79557