enricobuehler 8ee224e5db fix(android): advertise CLIENT_CAP_PAD_AUDIO, without which nothing is ever sent ...

A gap in the previous commits, and the same silent-failure shape as the two they
fixed. There are TWO negotiations, not one: the per-pad render capabilities that
ride a gamepad arrival (bits 8/9), which those commits set, and the SESSION-level
CLIENT_CAP_PAD_AUDIO in the Hello, which they did not. Without the latter the
host never sets HOST_CAP_PAD_AUDIO and emits no 0xD1 at all — so the per-pad bits
would have had nothing to gate, and the renderer would have sat on a permanently
empty plane with every other piece looking correct.

Threaded as an explicit `padAudioOk` on nativeConnect rather than advertised
unconditionally: the cap makes a Windows host provision pad endpoints at startup,
and a user who has pad audio switched off should not pay for that.

Found by tracing what an on-glass run against a real host would actually need,
not by a test — there is no test that could have caught it, since both halves are
individually well-formed.

2026-08-03 00:04:14 +02:00

..

src

fix(android): advertise CLIENT_CAP_PAD_AUDIO, without which nothing is ever sent

2026-08-03 00:04:14 +02:00

vendor/ndk

docs: repo-wide housekeeping — sync README & docs with the code as shipped

2026-07-10 09:13:42 +02:00

Cargo.toml

feat(android): tier-A pad audio — the 0xD1 plane on the pad's USB endpoint (WP9)

2026-08-02 23:39:25 +02:00