From 9524c79557a6adcbae8685d2176cdfd69a8ef00d Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 10 Sep 2026 18:49:59 +0000 Subject: [PATCH] wolf: grant /dev/uinput to the Steam container for Steam Input's virtual controller MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_013BWYKEERLA1a7gv86Z4W23 --- services/wolf.sh | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/services/wolf.sh b/services/wolf.sh index 2e7c322..416d29d 100644 --- a/services/wolf.sh +++ b/services/wolf.sh @@ -2384,12 +2384,27 @@ CATALOG = { f'{games}/retroarch:/home/retro/.config/retroarch:rw', f'{games}/esde-custom-systems:/home/retro/ES-DE/custom_systems:rw', f'{games}/esde-settings:/home/retro/ES-DE/settings:rw'], + # Steam Input needs /dev/uinput for the SAME reason the esde entry + # below needs it for AntiMicroX: it does not hand a game the raw + # controller device at all — it grabs the raw device exclusively for + # itself and creates its OWN synthetic virtual controller via uinput, + # then hands that synthetic device to the game. Confirmed live: + # without this, Steam's own controller test screen reads the raw + # device fine (it does not need uinput for that) and shows a correct + # Gamepad template, but every actual game — Steam title or non-Steam + # shortcut alike — sees no controller at all, since Steam Input can + # never create the virtual device it is supposed to hand off. Same + # devices= grant pattern as esde below: 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 device grant + # to actually open it. env=['PROTON_LOG=1', 'RUN_SWAY=true', - 'GOW_REQUIRED_DEVICES=/dev/input/* /dev/dri/* /dev/nvidia*'], + 'GOW_REQUIRED_DEVICES=/dev/uinput /dev/input/* /dev/dri/* /dev/nvidia*'], cap_add=['SYS_ADMIN', 'SYS_NICE', 'SYS_PTRACE', 'NET_RAW', 'MKNOD', 'NET_ADMIN'], security_opt=['seccomp=unconfined', 'apparmor=unconfined'], ipc_mode='host', ulimits=[{'Name': 'nofile', 'Hard': 10240, 'Soft': 10240}], privileged=False, + devices=['/dev/uinput:/dev/uinput'], ), 'esde': dict( name='WolfES-DE', title='EmulationStation', @@ -4813,13 +4828,28 @@ CATALOG = { f'{games}/retroarch:/home/retro/.config/retroarch:rw', f'{games}/esde-custom-systems:/home/retro/ES-DE/custom_systems:rw', f'{games}/esde-settings:/home/retro/ES-DE/settings:rw'], + # Steam Input needs /dev/uinput for the SAME reason the esde entry + # below needs it for AntiMicroX: it does not hand a game the raw + # controller device at all — it grabs the raw device exclusively for + # itself and creates its OWN synthetic virtual controller via uinput, + # then hands that synthetic device to the game. Confirmed live: + # without this, Steam's own controller test screen reads the raw + # device fine (it does not need uinput for that) and shows a correct + # Gamepad template, but every actual game — Steam title or non-Steam + # shortcut alike — sees no controller at all, since Steam Input can + # never create the virtual device it is supposed to hand off. Same + # devices= grant pattern as esde below: 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 device grant + # to actually open it. env=['PROTON_LOG=1', 'RUN_SWAY=true', - 'GOW_REQUIRED_DEVICES=/dev/input/* /dev/dri/* /dev/nvidia*'], + 'GOW_REQUIRED_DEVICES=/dev/uinput /dev/input/* /dev/dri/* /dev/nvidia*'], cap_add=['SYS_ADMIN', 'SYS_NICE', 'SYS_PTRACE', 'NET_RAW', 'MKNOD', 'NET_ADMIN'], security_opt=['seccomp=unconfined', 'apparmor=unconfined'], ipc_mode='host', ulimits=[{'Name': 'nofile', 'Hard': 10240, 'Soft': 10240}], privileged=False, + devices=['/dev/uinput:/dev/uinput'], ), 'esde': dict( name='WolfES-DE', title='EmulationStation',