fix(#38): controller_monitor must exclude the evsieve proxy virtuals (MCSS-slot*) - #149
Merged
Merged
Conversation
…(MCSS-slot*) Found by the on-Deck real-launch validation (2026-07-25): with the proxy on, a 4-up session launched fine and isolated correctly, but a live controller reconnect FAILED — the returning pad's slot never recovered input. Root cause: the per-slot evsieve virtuals advertise the PHYSICAL pad's real vendor:product (device-id=054c:…, so Controlify shows DS4 glyphs). So controller_monitor's raw enumeration — which drops the 28de Steam vendor but not 054c — enumerated the 4 MCSS virtuals as if they were real DS4 pads. It counted "5 external raw pads", warned about shared 054c VID:PIDs, and emitted spurious CONTROLLER_REMOVE/ADD for the VIRTUAL nodes (misrouted to wrong slots). The real pad's physical drop therefore never cleanly marked its slot disconnected, so when that pad reconnected, slot_claim saw a known MAC on a still-connected slot → REJECT (dup add) instead of RESUME → proxy_repoint_slot never fired → evsieve sat reopening the pad's stale old node (EACCES) and input never resumed. Fix: step 3b in _list_raw_external_pads drops any device whose Name matches MCSS-slot* (the name controller_proxy sets via evsieve --output name=MCSS-slotN), exactly as step 3 drops the 28de Steam virtuals. The vendor gate can't catch them because they intentionally carry the pad's 054c id. With them excluded the monitor sees only physical pads, so the reconnect's REMOVE/ADD flow cleanly → slot_release → slot_claim RESUME → repoint. Test: T2.22 — a physical DS4 + its MCSS-slot3 virtual (both 054c) → only the physical is eligible. Mutation-verified (disabling the gate makes both enumerate, failing T2.22). test_controller_monitor 21 → 22; no other suite affected; no new shellcheck warnings. The MCSS_CONTROLLER_PROXY default stays 0 — re-validate the live reconnect on the Deck with this fix before flipping it. Refs #38, #112, #142. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UZuoMpX28CbtGJbigVTv5H
This was referenced Jul 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by the on-Deck real-launch validation (2026-07-25). With the proxy on, a 4-up session launched fine and isolated correctly, but a live controller reconnect failed — the returning pad's slot never recovered input.
Root cause
The per-slot evsieve virtuals advertise the physical pad's real
vendor:product(device-id=054c:…, so Controlify shows DS4 glyphs). Socontroller_monitor's raw enumeration — which drops the28deSteam vendor but not054c— enumerated the 4 MCSS virtuals as real DS4 pads. It counted "5 external raw pads," warned about shared054cVID:PIDs, and emitted spuriousCONTROLLER_REMOVE/ADDfor the virtual nodes. The real pad's physical drop therefore never marked its slot disconnected, so the reconnecting pad hitslot_claim→ REJECT (known MAC, still "connected") instead of RESUME →proxy_repoint_slotnever fired → evsieve sat reopening the stale old node (EACCES).Fix
step 3bin_list_raw_external_padsdrops any device whoseNamematchesMCSS-slot*(set viaevsieve --output name=MCSS-slotN), exactly asstep 3drops the28devirtuals — the vendor gate can't catch them because they intentionally carry the pad's054cid. With them excluded the monitor sees only physical pads, so REMOVE/ADD flow cleanly →slot_release→slot_claimRESUME → repoint.Test
T2.22 — a physical DS4 + its
MCSS-slot3virtual (both054c) → only the physical is eligible. Mutation-verified.test_controller_monitor21 → 22; no new shellcheck warnings.MCSS_CONTROLLER_PROXYstays default 0 — re-validate the live reconnect on the Deck with this fix before flipping.Refs #38, #112, #142.
🤖 Generated with Claude Code