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

build.gradle.kts

feat(clients): reachability-probed presence + shareable Decky host management

2026-07-09 00:14:56 +02:00

proguard-rules.pro

feat: setup CI for Google Play Store submission and refactor UI

2026-06-18 11:51:40 +02:00