### System details

AMD 9800X3D, RTX 5080, Omarchy 4.0.1

### What's wrong?

**Environment**
- Omarchy 4.0.1-1
- Kernel 7.1.9-arch1-2
- Hyprland (Wayland), XDG_CURRENT_DESKTOP=Hyprland
- Steam 1.0.0.87-3 (native pacman package)

**Summary**
On a fresh Omarchy install, a Steam controller (tested: Steam Controller 2) is
correctly detected by Steam itself — shows as connected in Settings →
Controller, and drives Big Picture Mode / the Steam overlay fine — but is
**never recognized by any actual game**, regardless of engine or Proton
version. Confirmed with two unrelated titles (one Proton, one with its own
native controller support) — both fail identically.

**Root cause**
`/dev/uinput` is created with `crw------- root:root` (no group/ACL access)
and stays that way, even though Steam ships a udev rule for it:

    /usr/lib/udev/rules.d/60-steam-input.rules:
    KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

`getfacl /dev/uinput` shows no ACL entries at all, and
`sudo udevadm trigger --sysname-match=uinput` does not fix it — `uinput` is a
static device node created very early at boot (before udev's normal
add-event rule processing), so neither the `uaccess` tag nor a manually
added `GROUP="input"` udev rule ever gets applied to it. A user's own
membership in the `input` group is irrelevant since the device node itself
never picks up group/ACL permissions.

Since Steam (running as a normal user) can never open `/dev/uinput`, it
can't create the virtual XInput/gamepad device that games poll for. It
still manages its own UI/Big Picture navigation by reading the controller's
raw HID reports directly, which don't need `/dev/uinput` — which is exactly
why "Steam sees it fine, no game does" is the symptom, for every game.

**Reproduction**
1. Fresh Omarchy install, any Steam Input-capable controller connected.
2. `ls -la /dev/uinput` → `crw------- root root`, no trailing `+`.
3. Launch any game via Steam, try the controller → no input received.
4. Big Picture Mode / Steam Settings → Controller → works fine.

**Working fix**
`systemd-tmpfiles` re-applies permissions to static device nodes on every
boot, sidestepping the udev-timing issue entirely. Use type `z` (adjust
permissions of an existing file), not `c` (create device node) — `c`
requires a major:minor argument since it's meant to create the node from
scratch, which isn't needed here since the kernel already creates it:

    echo 'z /dev/uinput 0660 root input' | sudo tee /etc/tmpfiles.d/99-uinput.conf
    sudo systemd-tmpfiles --create

Verified: resetting `/dev/uinput` back to `root:root 600` and re-running
only `systemd-tmpfiles --create` (i.e. exactly what fires at boot, with no
manual chown/chmod involved) correctly restores it to `root:input 660`.

**Suggested fix**
Ship a `tmpfiles.d` entry for `/dev/uinput` as part of Omarchy's base
config/gaming setup, rather than relying solely on the udev `uaccess` tag,
which doesn't reach this particular static node.