Explain persistent /dev/uinput permission failures in Linux doctor/setup guidance #59

Summary

Make Linux uinput permission diagnosis distinguish a transient startup race from a persistent access denial, and document a reviewed systemd-tmpfiles option for existing static nodes that retain restrictive ownership or mode.

Evidence observed

• Omarchy issue #8373, 2026-08-26: the report describes /dev/uinput remaining root:root mode 0600, so Steam could navigate its UI but games received no controller. The author reports that systemd-tmpfiles with a z rule fixed this persistent case.
• Asahi-map issue #6, 2026-09-29: a separate startup race occurred because the helper opened the node before udev applied access about 80 ms later. The report proposes a static-node udev rule, early module loading, or retry.

Interpretation, fit, and confidence

The reports identify two different failure modes: a persistent restrictive mode on an already-existing static node, and a short-lived first-open race. OpenController's setup already emits static_node udev rules and the doctor checks current access, but its permission guidance is generic; a static-node rule alone does not repair every existing root-owned mode-0600 node. The observed reports are individual anecdotes, not prevalence evidence. Fit is high for Linux diagnostics and documentation; confidence is moderate.

Acceptance criteria

• Explain how to identify persistent denial from the current device mode/owner and how it differs from a transient node/module startup race.
• Document a reviewed systemd-tmpfiles option for adjusting permissions on an existing /dev/uinput node, alongside the existing udev/static-node guidance; explain the group/access implications.
• Keep commands reviewable and user-run. Do not silently write system files or run privileged commands.
• Add focused tests for any new doctor output or guidance formatting.
• Keep this issue independent of candidate Retry transient Linux uinput first-open failures within a fixed bound #58 except for the shared research gate; it changes no C helper retry behavior.

Ownership

• packages/native-linux-uinput/src/diagnostics.ts
• packages/native-linux-uinput/README.md and/or docs/linux-uinput.md
• Focused diagnostics tests if output changes

Non-goals

• Automatically changing device permissions, ownership, group membership, or system configuration.
• Adding retry behavior to the C helper; that belongs to candidate Retry transient Linux uinput first-open failures within a fixed bound #58.
• Claiming one permission remedy works for every distro or boot sequence.

Prerequisite

Cycle 8 research gate #57 must close with this candidate's scope selected before implementation begins. This issue does not depend on candidate #58.

No permissions are changed automatically.