Don't present a virtual Steam (28DE) pad on a host that already has a physical
Steam controller — the host's own Steam Input would then manage two Decks and
confuse player assignment.
- physical_steam_controller_present(): scans /sys/bus/hid/devices for a 28DE HID
device on a real (non-/virtual/) path.
- degrade_steam_on_conflict() in resolve_gamepad: a resolved SteamDeck /
SteamController with a physical Steam controller attached degrades to DualSense
(then the M5 uhid ladder); PUNKTFUNK_STEAM_FORCE=1 overrides (e.g. a remote-only
box with no competing Steam Input).
Validated on real hardware (a SteamOS Steam Deck @ .253 + a Bazzite host @ .41,
both running Steam):
- Conflict confirmed: the Deck-as-host already has its physical 28DE:1205 AND
Steam's 28DE:11FF XInput output pad live; a 2nd virtual 28DE = two Decks.
- Bind robustness: the virtual Deck binds hid-steam on a SECOND kernel (Bazzite
6.17.7, vs the dev box 7.0) and the kernel accepted our serial (the M1 fix).
- Criterion-4 (running-Steam recognition) PARTIAL: a userspace consumer (Steam/
SDL) engaged the virtual Deck (opened the hidraw, ran the lizard-disable +
settings sequence the kernel's Deck path skips) but emitted NO 28DE:11FF XInput
pad on the desktop — so Steam recognizes it enough to manage lizard mode but did
not promote it to a managed XInput controller (likely needs a Big-Picture/game
context, or a richer device; the 0x83/0xA1 attribute probes never fired, so it
wasn't a probe-reject either).
- The heuristic itself checks TRUE on the Deck, FALSE on Bazzite.
Workspace clippy/fmt/test green. Not pushed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
enricobuehler
4f40fa3cb7