Investigate: DualSense lightbar can stay dark while the Steam client holds the pad persistently

[NicolasPogorzelski]

Summary

During heavy connect/disconnect + mode-switch churn (field session 2026-07-15), both DualSense lightbars ended up dark in all modes and no host write could restore them, until the pads were power-cycled with Steam closed. This tracks whether there is a standing defect in reclaiming the lightbar from a persistently-holding Steam client, or whether the dark state only appears under abnormal churn.

Status: not a confirmed standing bug — needs a clean-room reproduction before any fix. In normal operation the daemon does win against a running Steam client (observed blue with Steam open earlier in the same session).

Diagnosis so far (what it is NOT)

• Not hardware. Firmware pairing pulse on power-on works; white player LEDs (LED-class) work on the affected pad. The two pads have different hw_version (0x0413 vs 0x0617) — a red herring, not the cause.
• Not the player-renumber feature. renumber() never writes the lightbar; the dark state occurred with no game running.
• The affected pad does process host output reports (a report with RELEASE_LEDS set turned its player LEDs off) — only the lightbar RGB stayed dark.

Hypothesis

The daemon's latch-heal (driver rebind via hidraw_gate "rearm") only fires when a hidraw holder closes its fd. The idle Steam client holds every pad's fd continuously and never closes it, so once Steam sets the firmware "light out" latch, the daemon's colour writes (raw HID and LED-class) don't win and no rebind is triggered to reset the latch. Repeated rebinds under churn can wedge the firmware into a state that no host write clears at all.

Reproduction protocol (to run on hardware)

Establish a clean baseline first:

1. systemctl --user restart controller-manager.service
2. Power-cycle both DualSense; Steam client running, no game; both pads in DualSense mode (native).
3. Confirm both lightbars are blue (steady state) — expected to PASS.

Then probe the suspected trigger:
4. Disconnect one pad past the remove grace, reconnect it; switch a pad native→Emulate Xbox→native a few times.
5. Observe whether either lightbar goes dark and stays dark (daemon no longer reclaims it) while Steam merely holds the pad (no game).

Capture on failure: journalctl --user -u controller-manager.service around the event, and the hidraw holders (ls -l /proc/*/fd → the pad's /dev/hidrawN, expect only comm=steam).

Acceptance criteria for a fix

• With the Steam client running (no game), the daemon's mode colour is shown and re-established within one backstop period after any connect/disconnect/mode-switch churn, without a manual pad power-cycle.
• No new input hitch introduced during normal play (a fix must not rebind the driver while a game is actively using the pad).

Candidate fix + trade-off (do not implement until reproduced)

A threshold/periodic rearm to reclaim from a persistent (non-foreign, never-closing) holder. Cost: a driver rebind yanks Steam's input grab → input hitch; must be gated to the idle-client case only (no running game, per steam_game_running()), and rate-limited.

References

• docs/decisions/steam-coexistence.md, docs/decisions/hidraw-gate.md
• Lightbar latch history: commits 0311bb4, 39d02b3; tests/test_lightbar_latch.py
• ROADMAP "Backlog / known limitations" (LED write race vs Steam Input, residual)

[NicolasPogorzelski]

Direction dependency with #5: #5 proposes removing the latch/rearm machinery (hidraw_gate "rearm" / driver rebind), while the candidate fix here would lean more on exactly that (a rate-limited rearm to reclaim the lightbar from a persistently-holding Steam client). These two must be decided against each other first — otherwise a fix here builds on machinery #5 is tearing down. Resolve the direction before implementing either.