Retry device-index resolution when a direct-connect index has no sensor - #34
Open
snekxs wants to merge 1 commit into
Open
Retry device-index resolution when a direct-connect index has no sensor#34snekxs wants to merge 1 commit into
snekxs wants to merge 1 commit into
Conversation
resolveDeviceIndex() trusted the first HID++2.0-answering index unconditionally for a non-receiver product id, never checking for a DPI/sensor feature the way the receiver-attached path already does. Confirmed on real hardware (a PRO X Superlight reached through its own product id): DEVICE_INDEX_DIRECT (0xff) can be a genuine admin/pass-through endpoint that answers the root feature query with no sensor behind it, while DEVICE_INDEX_RECEIVER (0x01) — the very next candidate — is the mouse itself. The old code latched onto 0xff and readStatus() threw NotAMouseError without ever trying 0x01. resolveDeviceIndex() now accepts an optional excluded-indices set (and a flag carrying forward that something already answered-without-a-sensor, for an accurate final error message); readStatus() calls it a second time, excluding the sensorless index, when its own DPI check comes back empty. The direct-connect fast path (no probe on the very first attempt) is unchanged and still covered by its existing test. Two new tests cover the fallback (mouse found on the second candidate) and the case where nothing has a sensor (still reports NotAMouseError, not the generic 'did not answer' error, since something did answer).
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.
Confirmed on real hardware: a PRO X Superlight reached through its own product id can answer HID++2.0 at DEVICE_INDEX_DIRECT (0xff) with no sensor behind it — a genuine admin/pass-through endpoint — while DEVICE_INDEX_RECEIVER (0x01), the very next candidate, is the mouse itself.
resolveDeviceIndex()'s direct-connect fast path latched onto the first HID++2.0-answering index unconditionally, without the DPI-feature check the receiver-attached path already does, so readStatus() threw NotAMouseError without ever trying the next candidate.
Fix: resolveDeviceIndex() accepts an optional excluded-indices set; readStatus() calls it again, excluding the sensorless index, when its own DPI check comes back empty. The direct-connect fast path itself is unchanged (still no probe on the very first attempt — existing test still passes).
Two new tests: the fallback finding the mouse on the second candidate, and the case where nothing has a sensor anywhere (still NotAMouseError, not the generic 'did not answer' error).
All 524 existing tests pass; tsc --noEmit is clean.