Park the DualSense-microphone-over-Bluetooth feature. Investigation
log + diagnostic infrastructure ship as-is for a future contributor
who wants to take another crack at it.
BLUETOOTH_AUDIO_NOTES.md (new): full hand-off doc covering what we
tried, what we found, where Sony / the kernel / the public RE
community currently stand on DS5 BT mic. Highlights:
- Real DS5 mic works fine over USB; our dongle's UAC1 descriptor
matches the DS5's exactly. The data path is correct.
- DS5 firmware on the test controller (build date Jul 4 2025) does
not stream microphone audio over the standard BT-HID L2CAP
channels. Confirmed by: every BT input report is a standard 79-
byte 0x31 report with no audio appended; no alternative report
IDs ever arrive; no bit of byte 2 correlates with mic-tagged
frames; bidirectional-audio hypothesis (aplay + arecord) did not
trigger streaming.
- Upstream awalol/DS5Dongle 'mic' branch's RE — 71-byte Opus at
data + 4 of frames where (data[2] >> 1) & 1 — appears to be
firmware-revision-specific; bit 1 of byte 2 is never set on the
current firmware.
- Linux kernel hid-playstation.c line ~1509 explicitly says
"Bluetooth audio is currently not supported" — the kernel
maintainers reached the same conclusion.
- Our state config (AllowAudioControl=1, MicSelect=Internal,
VolumeMic=0x40, MicMute=0, AudioPowerSave=0) matches exactly
what the kernel driver sends to enable the mic over USB. The
bytes are right; the BT-side trigger we're missing is not in
the standard DS5 protocol.
Diagnostic infrastructure stays in firmware (mic_diag.sh,
vendor feature reports 0xFD/0xFE, OLED Diagnostics rate counters,
Opus-decoder + mic_fifo wired but gated behind `if (false)` in
on_bt_data). Zero cost when mic-add is disabled; ready to flip back
on the moment someone identifies the right trigger.
README.md: short "known issue" entry pointing users at USB-direct
when they need the mic, and at BLUETOOTH_AUDIO_NOTES.md for the
research log.
Possible next steps for the curious:
- SDP browse the DS5 to discover non-HID L2CAP services
- BT sniffer (~$50-200) between a real PS5 and a DS5 during voice
chat — would settle the protocol question definitively
- Test with an older DS5 firmware revision (pre-2024) to see if
the BT mic path used to work and got removed
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Bump screen count 10 → 11 in the OLED Display Add-on section to
reflect the CPU/Clock screen added in v0.6.1.
- Update the cycle order to include CPU/Clock between Diagnostics and
BT Signal.
- Drop the per-screen ASCII mockups (they were noisy and out of date)
and link each screen section to a consistent web-preview screenshot
under assets/oled/. Eleven screenshots, named oled_sc01.jpg through
oled_sc11.jpg, captured from the OLED Preview tab of the web config
so every screen looks the same and the chrome/layout matches the
newly-flashed firmware.
- Rewrite the "KEY1 behavior by screen" table as a single "Button
reference" table. K0 = next, K1 = back, K1 long-press = brightness
cycle, K0+K1 hold = reboot. The per-screen state-change actions
(Triangle / R1 / D-pad) live on the controller now and are
documented per screen.
- Update Soft-reboot Recovery + the top-level Features bullet to
reflect KEY0+KEY1 chord replacing KEY0 double-click.
- Update per-screen descriptions: Lightbar uses R1 to cycle mode (not
K1); Trigger Test uses Triangle to cycle preset (not K1); Settings
text updated to mention the new D-pad cursor behavior on the web
preview.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add a dedicated "🛠️ Web Config Tool" section near the top of the
README so the deep link to https://marcelinevpq.github.io/DS5Dongle-
OLED-Config-Web/#config is discoverable. Lists the three tabs (Flash
Firmware / Config / OLED Preview) and what each one does end-to-end:
a brand-new Pico 2 W can go from "out of the box" to flashed and
configured without touching a terminal.
- BOOTSEL mode callout explaining what the physical button is, how to
enter the mode, and what the user sees (Pico mounts as a removable
drive). First-time flashers were getting stuck on this step.
- Performance / Overclocking section reworded: lead with "you don't
need to do anything — the overclock is baked into the firmware".
Stock UF2 sets 320 MHz @ 1.20 V automatically via vreg_set_voltage
and set_sys_clock_khz in src/main.cpp. The "if it fails to boot,
raise voltage / lower clock" line is scoped to people compiling
from source.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to #2 — the PR added a CPU/Clock OLED screen and bumped
kNumScreens from 10 to 11, but README still advertised 10 screens
in two places (header blurb + Features bullet).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
README: checkout from our master since our content (10-screen
docs, web-config link, multi-slot docs, Auto Haptics docs,
Acknowledgements, etc.) is the source of truth for the fork; upstream's
v0.6.0 README updates are mostly about their new web config tool which
we don't surface (we link our own fork's web config instead).
CHANGELOG: new [0.6.0-rebase] entry on top documenting (a) the
state_mgr adoption + speaker-fix hack drop, (b) the discoverable-rule
loosening for multi-slot, (c) the iSerialNumber restore that fixes
#100, and (d) verification results from the mid-rebase flash.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The low-battery indicator is critical info — keep blinking even when
the user has the LED disabled (Speaker mute toggle). Steady-state
LED still respects the flag: when battery recovers or charging
starts, the LED returns to off if the flag is set, otherwise to the
existing connected = solid-on state.
(cherry picked from commit 775346cd29d9a3c566309ec7d29db80f0b6979f1)
Blink the Pico onboard LED at 1 Hz when the connected DualSense
reports PowerPercent <= 1 (i.e. <= 10%) and PowerState == Discharging.
Source data is byte 52 of the BT 0x31 input report, already copied
into interrupt_in_data; no new BT parsing required.
The new module owns the LED only while it is actively blinking; it
detects controller disconnection via stale-report timeout and steps
out, so bt.cpp's existing connect/disconnect LED handling stays in
charge in all other states. Honors disable_pico_led.
Gated by -DENABLE_BATT_LED=ON (default). With the option off, the
source file is not compiled and behavior is identical to upstream.
CI gains a compile-only check for the OFF flavor.
(cherry picked from commit 2f8ea73c9fb695e24e7cc3329db7cb925e82e1c9)
