Bring both READMEs up to v0.6.10's user-facing capability:
- Status screen: note the L3/R3 stick-click inverse-flash indicator and
the ~Nm charge-time token next to the battery.
- Gyro Tilt screen: per-unit factory IMU calibration, dot centres when the
controller lies flat, and tilt moves the dot in the matching direction.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Verified 2026-06-07: Cyberpunk on GOG/Heroic fires adaptive triggers in
real gameplay, 1:1 with Steam. Corrects the recipe across README,
CHANGELOG, and the new DUALSENSE_GAME_LIST.md:
- no launch option needed on Wine 11 (PROTON_ENABLE_HIDRAW now legacy)
- works on BOTH Steam and Heroic; Heroic needs Steam fully quit + no
global PROTON_PREFER_SDL
- XInput-only games (Ghostrunner, Control) give rumble but no triggers
by engine design, not a dongle limit
- OpenRGB confirmed a non-issue
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Inline warnings on the Config and Remap tab descriptions (in addition to the
existing caveat block) so users on the native-trigger firmware don't try the
browser config tool and hit a silent failure. The reports those tabs use
(0xF6/0xF7) are undeclared on this firmware so WebHID can't reach them; OLED
on-device config and a Linux hidraw path still work.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CHANGELOG: headline + Added/Changed/Known-tradeoff for the native-trigger work.
README: a Features bullet, a "Linux: native adaptive triggers (Proton)" setup
section with every launch option in a reference table, and a caveat that the
WebHID Config/Remap tabs are disabled on this firmware. CLAUDE.md: a load-bearing
gotcha -- the HID descriptor must stay byte-identical to a real DS5 (289 bytes)
and feature reports 0x09/0x20/0x05 must serve the real cached controller data, or
native game triggers silently break.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
README: add a "Button remapping" feature bullet and a "Remap tab" entry
under the Web Config Tool section. CHANGELOG [Unreleased]: add a Companion
web tool note documenting the visual Remap editor + Zacksly CC BY 3.0
asset attribution.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The BT mic decode path gained a decoded-frame jitter buffer (8 frames) drained
at a steady 10 ms playout cadence. Bursty BT delivery is smoothed; a dropped
mic frame during an active session is concealed with an Opus PLC frame
(opus_decode(decoder, NULL, 0, ...)) instead of leaving a hole the host hears
as a click/dropout. Playout pre-buffers 3 frames and stops after 300 ms of no
real frames so it never emits comfort noise when the mic is idle. New "Mic PLC:"
Diagnostics counter climbs only when concealment fires (a live link-quality
gauge). Verified on hardware: forced BT loss kept captured audio gap-free
(longest zero-run ~0 ms) while the counter climbed; clean link leaves it idle.
Adds ~30 ms mic latency (the pre-buffer). Design ported from
SundayMoments/DS5_Bridge (credit). Unreleased — batching with the next feature.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
BT microphone over Bluetooth: the DS5 mic now works over the dongle's BT
pairing — decoded from the controller's Opus stream to the USB capture
endpoint. Hinges on pkt[4] bit 0 (mic-enable) in the outbound 0x36 audio
report; credit to awalol (upstream) for identifying it. Mic-tagged 0x31
frames ((data[2]>>1)&1) are ALWAYS diverted out of the input path (decoded
when on, dropped when off) so Opus payload can never corrupt sticks/buttons.
Always-on via a sticky-latch keep-alive that only runs post-enumeration
(tud_mounted) so it never floods the fresh-pair handshake (which otherwise
delayed controller detection past the watchdog and tore the link down).
Toggle: bt_mic_enable config field (default on) — OLED Settings + web config.
README gains a "DualSense Microphone over Bluetooth" section;
BLUETOOTH_AUDIO_NOTES.md rewritten from "dead end" to the working mechanism.
USB 3.0 connection watchdog: auto-recovers a stalled connection (re-inquiry)
instead of hanging on the amber lightbar, for USB 3.0 ~2.4 GHz RF interference
that desensitizes the CYW43 BT radio. Re-enabled the ACL-fail / auth-fail /
create-connection-reject recovery paths. README "USB 3.0 ports & Bluetooth
interference" section with mitigations.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extends the firmware's 0xFD vendor feature report from 32 to 44 bytes
to carry the three host -> dongle -> BT trigger counters added in
5da1be4 (host_out02_total / host_out02_trig_allow / host_out02_to_bt).
mic_diag.sh's bt-trace decoder reads them and prints a one-line
verdict so the user can triage issue #3 in one terminal command
instead of switching to the OLED Diagnostics screen mid-game.
Verdicts encoded:
host02 > 0, trig == 0 -> host driver never sets the trigger
Allow bits; not a firmware problem.
trig > 0, tx < trig -> trigger Allow bits arrive but the
speaker-active gate in main.cpp
swallowed them.
full chain populated -> dongle delivered, controller didn't
actuate; Sony BT-side limit.
The 0xFD report ID stays undeclared in the HID descriptor — Linux
hidraw ioctls don't enforce that and WebHID never sees these reports
(config goes through 0xF6). bt-trace's IOCTL_SIZE bumped to 45
(1 byte for the kernel-prepended report ID + 44 bytes payload).
Docs:
README.md - new "Diagnostics & debug tooling" section walks
through the four mic_diag.sh subcommands; previously
the script was only mentioned inside
BLUETOOTH_AUDIO_NOTES.md.
README.md - Diagnostics-screen description updated for the
scrolling row-list + cross-link to bt-trace.
CLAUDE.md - "Where features live" gets a host-side-diagnostics
entry explaining how to extend the 0xFD payload and
wire it into bt-trace's decoder.
CHANGELOG - records both the firmware extension and the README
discoverability fix.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
CHANGELOG [Unreleased]:
- Added: OLED idle power ladder (breathing dot @ 2 min, full off @ 15 min).
- Added: host02 / trig / tx trigger-flow counters for issue #3 triage.
- Added: D-pad scrolling Diagnostics screen.
- Changed: flush_fb split into flush_fb_raw + chrome wrapper.
- Changed: Diagnostics row order re-prioritized for trigger triage.
README — replace stale "auto-dim after 5 min idle" line with the
new three-stage power ladder description.
CLAUDE.md — new "Idle power ladder" paragraph in the Architecture
section (state machine + wake events + why contrast-register dim
doesn't work on this panel), and a new entry in "Where features
live" for adding diagnostic rows.
There's a stray older `[Unreleased]` heading at CHANGELOG.md:112
that looks like leftover release content (speaker/haptic regression
fix + Audio Auto Haptics) which actually shipped in an earlier tag.
Not touched here; flagging for a future CHANGELOG hygiene pass.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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)
