enricobuehler
a9a514dea0
windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m0s
ci / docs-site (pull_request) Successful in 1m24s
apple / swift (pull_request) Successful in 1m30s
apple / screenshots (pull_request) Skipped
ci / web (pull_request) Successful in 2m34s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m5s
ci / rust-arm64 (pull_request) Successful in 3m26s
android / android (pull_request) Successful in 4m9s
ci / rust (pull_request) Successful in 7m51s
Two faults in the rich-feedback plane — the lightbar, player LEDs and adaptive triggers — both of which leave a controller physically wrong with nothing to put it right. Nothing reset the pad on teardown. Rumble stops on its own the moment nothing renews it, but the rich planes are LATCHED in the controller's firmware: they outlive the stream, the app, and being unplugged. Ending a session while a game held a weapon's trigger resistance left the physical trigger stiff on the desktop afterwards, and its lightbar showing whatever the game last set, until another game happened to set one. The Apple client already reset on teardown; the desktop and Android halves now do too — triggers to mode 0x00, lightbar dark, player indicator cleared. Android writes them EP0-direct like its rumble stop, because the reader thread is stopping and the queue would never drain. A single lost datagram stranded the pad on the previous value. The plane is deduped AND rides unreliable datagrams, which is a bad pairing: a change is forwarded exactly once, so when that datagram is dropped nothing re-derives it — the game keeps sending the same value and the dedup swallows every copy. The pad then holds the last weapon's trigger effect, or the last lightbar colour, for as long as the game keeps that setting, which can be the rest of a level. The dedup already remembers the current state, so it can repair itself: it now re-emits what it has latched once a second. Slow on purpose — this is a repair mechanism, not a transport, and every value is idempotent, so a client that did receive the original simply re-applies it. A forward re-stamps the clock, so a plane the game is actively driving never pays for a renewal it does not need. One-shot pulses are deliberately excluded from that renewal: replaying a trackpad haptic would be a new pulse, not a repair. Raw passthrough reports are excluded too — the device's own refresh cadence already re-sends them verbatim.