Open
Conversation
Member
|
Well huh. Our json schema check when building the device config should've crashed the whole build on that misspelling! So there's even more bugs to fix here. Thanks for calling that out, will file that as a followup. @blackspherefollower You're up for the device impl review. |
Collaborator
blackspherefollower
left a comment
There was a problem hiding this comment.
Minor snag on the copyright header, otherwise nice concise and clean
| @@ -0,0 +1,81 @@ | |||
| // Buttplug Rust Source Code File - See https://buttplug.io for more info. | |||
| // | |||
| // Copyright 2016-2024 Nonpolynomial Labs LLC. All rights reserved. | |||
blackspherefollower
approved these changes
Nov 26, 2025
Collaborator
|
@qdot This looks good to me: I've not updated my OSSM to the most recent firmware yet to test though |
You will not be missed. Fixes buttplugio#842
You will also not be missed. Fixes buttplugio#841
…n skipping
Adds a new TestCommand::VersionGated { min_spec_version, commands } variant
that groups test commands requiring a minimum protocol spec version. The
filter_commands() helper pre-flattens device_commands before execution,
expanding VersionGated groups only when the runner's version qualifies.
Each version runner (v2/v3/v4) now passes its version constant to
filter_commands(), causing v3+-only command groups to be silently skipped
in the v2 runner. This avoids the existing bug where Scalar Messages were
no-op'd but the paired Commands block still waited for hardware writes that
never arrived, causing timeout panics.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Updates 16 YAML device test cases that are included in the v2 test suite but contain Scalar (or other v3+-only) message commands. Each Scalar Messages+Commands pair is wrapped in a VersionGated block with min_spec_version: 3, so the v2 runner correctly skips both the send and the expected hardware output together. Files with all-Scalar device_commands (hismith_*, tryfun_blackhole, xibao) now wrap their entire Scalar sequence in a single VersionGated block, leaving only the Stop+Commands pair at the top level for v2. Files with mixed Vibrate/Scalar sequences (bananasome, cowgirl, feelingso, galaku, galaku_nebula, lelo_idawave, lovense_max, luvmazer, sakuraneko_koikoi, tryfun_meta2) wrap only the Scalar sections, leaving Vibrate/Rotate/Linear commands to run on all spec versions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Removes the /* */ block comment that was suppressing all v2 device protocol tests. Also fixes a tracing_subscriber::fmt::init() panic that occurred when tests ran in parallel (comment it out, matching v3), and excludes the two TryFun protocols from the v2 list: their command data embeds a monotonically increasing counter, so the expected Stop bytes assume all prior Scalar commands ran — which v2 correctly skips via VersionGated, but that invalidates the counter-dependent assertions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Implement V0 client, device, event loop, and connector for the Buttplug test system. V0 is significantly simpler than V2 as it only supports SingleMotorVibrateCmd and StopDeviceCmd. Changes: - client.rs: V0 client with V0-specific message types and handshake - device.rs: V0 device with simplified message list (no structured attributes) - client_event_loop.rs: Event loop handling V0 messages - client_message_sorter.rs: Message ID pairing for V0 - in_process_connector.rs: In-process connector for V0 - mod.rs: Test runner that filters V0-unsupported commands Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Create V1 client implementation by copying and adapting the V2 client, making targeted type changes for the V1 protocol. The V1 protocol is nearly identical to V2 with the same device commands (Vibrate, Rotate, Linear, Stop) but different message enum types and no Battery support. Key changes: - Replace all V2 message types with V1 equivalents (ButtplugClientMessageV2 -> V1, ButtplugServerMessageV2 -> V1, etc.) - Remove battery_level() method entirely from device.rs (V1 has no BatteryLevelCmd) - Update handshake to use ButtplugMessageSpecVersion::Version1 - Add Battery command panic in mod.rs run_test_client_command - Use filter_commands(x, 1) for V1 protocol version filtering Files created in /crates/buttplug_tests/tests/util/device_test/client/client_v1/: - mod.rs - Test runner with V1 type filtering - client.rs - ButtplugClient with V1 message types - device.rs - ButtplugClientDevice without battery_level() - client_event_loop.rs - Event loop with V1 types - client_message_sorter.rs - Message sorter for V1 - in_process_connector.rs - In-process connector for V1 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add ButtplugClientJSONSerializerV0 and ButtplugClientJSONSerializerV1 to connector/mod.rs following the pattern of V2/V3 serializers. These provide type-correct message serialization for each protocol version instead of using the generic ButtplugClientJSONSerializer (which is for V4 messages). - Update ChannelClientConnectorV0 and ChannelClientConnectorV1 type aliases to use the new version-specific serializers. - Export ButtplugDeviceMessageNameV1 from buttplug_server::message::v1 module. This enum was defined but not re-exported, causing unresolved import errors in client_v1/device.rs. - Add CopyGetters derive and getter attribute to GenericDeviceMessageAttributesV1::feature_count. The V1 version had the field but no public getter method, causing method-not-found errors. V2 already had this pattern; now V1 matches. - Fix error conversion in client_v0/client_message_sorter.rs. Change from e.into() to e.original_error().into() to properly convert ErrorV0 to ButtplugClientError by first extracting the underlying ButtplugError. All compilation errors are now resolved. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds v1 embedded and JSON test functions to test_device_protocols.rs, using the same test case list as v2. Battery tests are wrapped in VersionGated(min: 2) since v1 has no BatteryLevelCmd. Fixes a pre-existing bug in ClientDeviceMessageAttributesV1 where stop_device_cmd, single_motor_vibrate_cmd, fleshlight_launch_fw12_cmd, and vorze_a10_cyclone_cmd fields were missing #[serde(rename)] attributes, causing them to serialize as snake_case instead of PascalCase. This made V1 DeviceAdded messages fail JSON schema validation in the remote transport path. V0 test functions are added but commented out pending YAML VersionGated wrapping for Vibrate/Rotate/Linear commands (min_spec_version: 1). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds SingleMotorVibrateCmd support to the V0 client device and test runner. For single-vibrator devices, SingleMotorVibrateCmd produces identical hardware output to VibrateCmd, so existing YAML assertions work without changes. Enables 48 embedded + 48 JSON v0 tests (96 total). Excludes 14 devices: 7 with multi-vibrator hardware (SingleMotorVibrateCmd addresses all motors, changing expected bytes), and 7 with top-level Rotate/Linear commands unsupported in V0. Fixes a pre-existing bug in the JSON schema: DeviceMessagesV0 enum was missing StopDeviceCmd, causing V0 DeviceAdded messages to fail schema validation in the JSON transport path. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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
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.
OSSM v3 will be releasing soon...updated BLE specs are committed. No absolute positioning in this round, speed control only.
(and i noticed luvmazer had a typo)