mirror of
https://github.com/ddeverill/SteamlessController.git
synced 2026-10-22 06:32:20 -05:00
Dylan DeverillandClaude Opus 5
255f4f9cad
vigem_connect returns VIGEM_ERROR_BUS_NOT_FOUND both when no bus driver is installed and when one is present and did not answer, and the client never records which product's bus it tried. The app inferred "driver missing" from that error, so a driverMissing=1 that happened to be right was indistinguishable from one that was wrong — which is most of why #65 took as long as it did to pin down. ViGEmBusInfo enumerates the interface GUID directly. The failure line is now followed by what the machine actually has, and driverMissing is set from an empty enumeration rather than inferred from an error code with several causes. The GUID comes from the vendored client's own header rather than a copy, so updating third_party cannot leave a stale value behind here. That matters because the header instructs forks to change it, and several products ship one: measured on the #68 reporter's machine, which carries both the Oculus and Virtual Desktop forks, neither publishes this GUID and only the Nefarius bus appears. An empty result therefore does mean no usable bus, which is what makes it safe to drive the "go install the driver" advice from. It also retires the theory that the client had been connecting to a fork. A disabled bus reads the same as an absent one — the devnode stays present and reports a problem, but its interface is withdrawn entirely — so that case belongs in the empty-list wording rather than in a state of its own. ViGEmBusProbe prints the same inventory, since "vigem_connect failed" is not a question a reporter's log can answer on its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>