mirror of
https://github.com/d4rken-org/capod.git
synced 2026-09-14 18:26:11 -04:00
darken
734e15c94d
Follow-up to the previous commit, which left the wrong half of this in place. Distrusting the report only while the request was outstanding meant that four seconds later the rejection cleared the pending mode, the bogus value came back, and the user was shown an error for a mode change that had actually worked. The two cases have different signatures, both readable from state the engine already holds: - A refusal echoes the mode the device is staying in, quickly. Captured Off refusals answer in 25-267ms with the previous mode. - The Pro 3 misreport answers with a third mode, neither the one requested nor the one it was in, at normal change latency (815-1010ms). So an echo that is neither the requested nor the previous mode is treated as an unusable report rather than a refusal: no re-send of a write that already took effect, no rejection, no error, and the requested mode is recorded as current. Refusals still work, which is what the Off rejection message and the Allow Off learning depend on. This is deliberately engine-local. Seeding the cycle mask and Allow Off belief from the device profile into the session would have encoded the rule directly, but it inverts the current engine-to-profile data flow and creates a belief that no device report can ever correct, since AirPods never report 0x1A or 0x34. librepods keeps the same knowledge in its service layer and preferences, not in its protocol manager. The fault is per-session rather than per-request: across four sessions today the pods either misreported every Adaptive write or none of them. The heuristic is covered by unit tests but has not yet been observed handling a live bad session.