Conversation
GPT made these scripts. Good bot.
Print stringified result structs in debug builds
That's a lot of packets.
Client also log disconnects
..And of course, more Protocol fixes.
Basically vibed, with the references mentioned in this PR description. Let's hope this can work oneshot...
...Who said we need these anyways. Got something better.
Optional (of course). Thanks to an idea @Amrsatrio had.
For now. Maybe I'll keep this?
Use it by drag-n-drop folders into the UI. Or the with the CLI args.
Reset debugger packet counter with new dropped files
Bindings should know how to take care of this on their own. At last we're clean...
...I was too hopeful about Bluetooth APIs in other langs
I do miss my Arch Linux box.
Clean up WaitForCompletion.h build warning
C++ Allocators do not get used by libmdr/bt itself as now anyways. For STL Xlen checks, downstream can do that if they *really* want it: For this hack to work - do note that the current source misses a `namespace std` decl and with these type of usages, you'd need to link CRT static as well.
|
I tried testing the nightly for macOS, but it seems like it doesn't work with Sequoia. Is Tahoe or later required to use the Mac build?
|
Owner
Author
|
@geekifier ae71d32 should solve this, please get the new builds from nightly. I guess Actions updated their macOS runner to Tahoe which defaulted to be the macOS build targets. Verified on my own Mac Mini running on Sequoia 15.7.8. |
|
Confirmed the updated nightly build opens on macOS 15 / Sequoia. |
Sound Connect's "Fixing playback device" pins audio to the current playback device so the headphones stop handing it over to the other multipoint device. SOURCE_SWITCH_CONTROL's param byte carries this, inverted against the feature: the wire value is 1 while switching is free and 0 once the device is fixed. Verified on WF-1000XM5 (fw 6.1.0) by toggling the setting in Sound Connect and reading the byte back, then driving it the other way and confirming the padlock appears in the official app. SourceSwitchControlResult is surfaced too - the headphones refuse to fix while a call is in progress or the voice assistant holds priority, which Sound Connect reports as a dialog and would otherwise look like a dead button. The added rx packets are a real capture of the not-fixed state and of a FAIL_CALLING refusal. mdrHeadphonesGetFeature's upper bound was pinned to the last feature id, so any newly added MDR_FEATURE_* read back as invalid. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RKt3Lk68pt5yr92YV1iTqn
…rsion Rebased onto the current MDRProperty API (pending()/override() replace submittedDirty()/commitOneShot(), renamed underneath this branch), and renamed the public surface as requested in review: MDR_FEATURE_PLAYBACK_DEVICE_FIX becomes MDR_FEATURE_SOURCE_SWITCH_CONTROL, mdrHeadphonesGet/SetPlaybackDeviceFixed becomes mdrHeadphonesGet/SetSourceSwitchControl, MDRPlaybackFixResult becomes MDRSourceSwitchControlResult - matching SOURCE_SWITCH_CONTROL and the packet debugger instead of translating Sound Connect's Japanese-derived label. libmdr now tracks the wire value directly (1 = switching free) instead of mangling it into a "fixed" flag; the one inversion left lives in Client.cpp, where "Fixing playback device" is a UI concept. Also dropped two MDR_LOG_DEBUG calls in the SOURCE_SWITCH_CONTROL notify/param handlers, matching the other protocol handlers, which don't log there either. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qy2qqZHg5iaikSzDSNMT9o
Fix playback device on multipoint
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
NOTE: Do not be alarmed by the LoC changes. Most of which are generated code for the legacy protocol.
This PR also introduces fully auto-generated protocol definition for V1/V2 themselves through IDA. Courtesy of GPT 5.6 Sol for writing those scripts.
Test suites for packet playback are added too to validate the packets themselves. This should work for both protocol versions.
Be patient as this will take quite a while to land as I don't have devices to test myself. Though if anyone's willing to test, get your nightly builds on this branch here:
Linking to issues that requested support before:
Referencing implementation for XM3/XM4s by:
CC @Amrsatrio. I think we can prepare a proper v2.0 release once this is done.
Also coming up:
Compile with CMake option
-DMDR_CLIENT_DEBUGGERwhen building the client to have this available in the top-left drop down menu.