Skip to content

fix: read a DualSense over Bluetooth whatever its report padding - #132

Merged
lippdev merged 3 commits into
lippdev:mainfrom
nextestudios:fix/dualsense-bluetooth-hid
Oct 1, 2026
Merged

lippdev merged 3 commits into
lippdev:mainfrom
nextestudios:fix/dualsense-bluetooth-hid

Conversation

@nextestudios

Copy link
Copy Markdown
Contributor

Summary

A DualSense over Bluetooth could read as "no buttons pressed" in the places that depend on SonyHidReader (the session menu over a game, the shortcuts).

The reader told the DualSense's two report layouts apart by the size of the bytes read: report ID 0x01 with at least 64 bytes was parsed as the USB layout (buttons at offset 8). But the DualSense's basic Bluetooth report has the same ID (0x01, buttons at offset 5), and ReadFile may hand every report back padded to the size the HID descriptor declares (78 over Bluetooth, report 0x31). Padded, the basic report was parsed with the USB offsets and every button read as released. Over Bluetooth the pad stays in this basic mode unless something else switches it, so the reader never saw it.

  • ControllerMapping.SonyButtons takes the declared input report length (HIDP_CAPS.InputReportByteLength, new optional parameter, default 0 = old behaviour) and treats ID 0x01 as USB only when that length is 64 (or unknown) and the data is ≥ 64 bytes. The padding no longer matters; the DS4 and USB layouts are unchanged.
  • SonyHidReader passes the declared length and now logs, once per pad, the first report (ID, size, declared size) and any unknown report ID, so a pad that reads wrong can be diagnosed from consolemode.log alone.
  • docs/TESTING.md: DualSense over Bluetooth/USB checks and the new log line.

Validation

  • New tests in ControllerMappingTests: the basic Bluetooth report as 10 bytes and padded to 78, the USB report with a declared size of 64, and the known report IDs; the existing layout tests still pass.
  • Verified on a real PC with a PS5 controller together with the other two fixes from this batch (build from my fork).
  • App build and dotnet test are left to CI.

🤖 Generated with Claude Code

nextestudios and others added 3 commits September 30, 2026 23:19
The DualSense's basic Bluetooth report has the same ID (0x01) as the USB
report but a different layout; the reader told them apart by the size of the
bytes read (>= 64 = USB). When Windows hands the report back padded to the
declared Bluetooth size (78), the basic report was parsed with the USB
offsets and every button read as released. Decide by the size the HID
descriptor declares instead, and log the first report of each pad (ID, size,
declared size) and any unknown report ID, so a pad that reads wrong can be
diagnosed from consolemode.log.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ No new issues found.

Reviewed changes The PR updates Sony HID report parsing and documents Bluetooth/USB verification for DualSense controllers.

  • Report layout selection: Uses the declared HID input report size to distinguish padded basic Bluetooth reports from the DualSense USB layout, and adds report diagnostics.
  • Coverage and manual checks: Adds parser tests plus Portuguese/English changelog entries and DualSense Bluetooth/USB checks in docs/TESTING.md.

Pullfrog  | View workflow run | Using GPT Luna | 𝕏

@lippdev
lippdev merged commit 660df98 into lippdev:main Oct 1, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants