The Problem

The multi-seat gaming setup runs Steam in a gamescope session as a systemd user service. The machine has two users: the gaming user who owns the gamescope service, and a separate work user. Both users are on seat0. Switching to the work user while the gamescope session is running caused the DualSense controller to stop responding in Steam.

Why the Controller Goes Through hidraw

Part 3 explains this in detail. The short version: TemporaryFileSystem=/dev/input in the gamescope service hides all evdev devices from the service process tree. Steam Input bypasses this entirely - it reads the DualSense through /dev/hidraw* (the raw HID interface) for full-feature support: adaptive triggers, haptics, gyro, touchpad. The evdev path is never used.

What’s Happening: uaccess

The DualSense hidraw nodes have TAG+="uaccess" in systemd’s udev rules. This tag tells logind to manage the device’s ACLs automatically: the active session’s user gets read/write access, and that access is revoked when a different user session becomes active.

With two users on seat0, switching to the work user makes their session active. logind updates the ACL on the DualSense hidraw node: the work user gains access, the gaming user loses it. Steam in the gamescope service can no longer open the device.

The Fix

The input group has static read/write permissions on /dev/input/* devices. The same approach works for hidraw: a udev rule that sets GROUP="input" on the DualSense hidraw nodes gives any member of the input group persistent access, independent of which logind session is currently active.

Find the Device

First, identify the hidraw node while the controller is connected:

grep -l "0CE6" /sys/class/hidraw/*/device/uevent 2>/dev/null

Then get the udev attributes of that node. The controller may appear at a different index each time it connects, so use the path returned by the command above:

udevadm info -a /dev/hidrawN | grep KERNELS

The parent HID device appears as KERNELS=="0005:054C:0CE6.001B" over Bluetooth and KERNELS=="0003:054C:0CE6.001D" over USB. The leading four hex digits are the bus type code (0005 = Bluetooth, 0003 = USB). The trailing instance suffix changes between connections.

Write the udev Rule

A single rule covers both transports using a wildcard on the bus type and instance:

# /etc/udev/rules.d/72-dualsense-gaming.rules
SUBSYSTEM=="hidraw", KERNELS=="????:054C:0CE6.*", MODE="0660", GROUP="input"

054C is Sony’s vendor ID, 0CE6 is the DualSense product ID.

Add the User to the input Group

sudo usermod -a -G input $USER

The new group takes effect after re-login. systemd --user starts at login time and inherits the groups from that session - restarting the gamescope service alone is not enough. Re-login once, then the service will pick up the input group on next start.

Apply the udev Rule

sudo udevadm control --reload
sudo udevadm trigger --subsystem-match=hidraw

Verify the permissions on the node found earlier:

ls -la /dev/hidrawN
# crw-rw---- 1 root input ... /dev/hidrawN

The DualSense now remains accessible to the gaming user regardless of which user is active on seat0.

Other Controllers

The rule above is DualSense-specific. For other controllers, the vendor and product IDs can be found in Valve’s steam-devices/60-steam-input.rules, which maintains a comprehensive list of supported gamepads. The same MODE="0660", GROUP="input" pattern applies - replace 054C:0CE6 with the relevant vendor and product ID for your controller.

Alternatively, a single broad rule covers everything:

SUBSYSTEM=="hidraw", MODE="0660", GROUP="input"

This grants the input group access to all hidraw devices, including keyboards and mice that expose a hidraw interface. In the gamescope setup from Part 3, the service’s TemporaryFileSystem=/dev/input already prevents gamescope itself from opening desk input devices, so the broader rule does not introduce any new input bleeding into the TV session.