Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
For stroke mode, we want to set the devices to it's most capable. I wish there were a good way to control this though; oscillateWithDepth would be a good fit here.
updated version files from changes in the `dev` branch all integrated tests passed; protocol verified against actual device
…ing to zero stops machine immediatly while speed is still bought down in the background.
Switch disconnect from info level to warn level. Add Tremblr identifier to protocol definition.
Adds the Svakom Fatima Pro (BLE name SL278B): vibration, suction, oscillation patterns, and heat. The device drives with just connect + write to FFE1 (tx-only) - no init handshake or notification subscribe is required - so the protocol uses generic_protocol_setup! with no initializer. Closes #907.
* Punisher * Prismcy * AresIII Also swapping the features on the Perseus
* Mira * Vero * Nexo
The Yiciyuan FJB-01 / FJB-02 (役次元) are JieLi-SoC BLE strokers advertising as "YCY-FJB-01" and "YCY-FJB-02" with three independent actuators: - stroke axis (linear oscillation) - vibe axis (vibration motor) - axis_c (third haptic motor driven in app-recorded patterns) Each axis takes an unsigned 0..=0x14 level; the 16-byte control packet is sent to characteristic ff41 under service ff40 as: [0x35, 0x12, stroke, vibe, axis_c, 0x00 x11] Battery push arrives on the same notify characteristic as a `35 13 01 <pct>` frame mixed with 10Hz uptime ticks (`35 14 ..`); the handler filters by prefix. FJB-01 is verified against physical hardware. FJB-02 is its successor in the same product line; the official app routes both through an identical code path (same vuex state, same hex-stringed motor frame, same BLE service/characteristic UUIDs), so the same protocol module covers it. Hardware verification welcome. Adds: * buttplug_server_device_config/device-config/protocols/yiciyuan.yml * buttplug_server/src/device/protocol_impl/yiciyuan.rs * tests/.../test_yiciyuan_protocol.yaml (FJB-01) * tests/.../test_yiciyuan_protocol_fjb02.yaml (FJB-02) * regenerated buttplug-device-config-v5.json (version 5.6) Test commands gated on protocol v3+ since v0-v2 single-axis Vibrate semantics don't map cleanly to a multi-actuator device. All 828 device protocol tests pass on debug build.
Stop commands were fire-and-forgot into the device io channel, where message_gap batching could leave the stop write sitting in pending_commands until the batch deadline. Since shutdown order is stop then disconnect, the disconnect routinely beat the deadline and dropped the pending stop write unflushed, leaving the device running. The io-channel payload is now DeviceTaskMessage, carrying the commands plus an optional oneshot write-acknowledgement sender. A message with an ack is urgent: the io task merges it into any pending batch (existing dedupe), flushes everything to hardware immediately regardless of the batch deadline, then fires the ack. Messages without an ack keep the exact prior batching behaviour, so normal output is unchanged. The stop path accumulates the hardware commands from every per-feature stop OutputCmd into a single write-acknowledged batch and awaits the ack, so stop() (and therefore stop_devices()/shutdown) resolves only once the stop write has reached hardware. The wait is bounded by a runtime-agnostic 1s timeout; a wedged or dead device resolves Ok rather than hanging shutdown. The io task's channel-close exit now best-effort flushes pending_commands first so a stop in the batch window still lands; the hardware-Disconnected exit deliberately does not flush, since the hardware is gone. Mirrors the device-level behavioural fix from task-manager-v1 (fb8d6e0) without the global task registry.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
When the event loop replaces a colliding device entry, it removes the old device from the map itself before disconnecting it. The disconnect's direct terminal notification was then queued into the loop's own event channel and processed after the replacement device (same identifier) was inserted, removing the wrong device. Awaiting that send from inside the loop was also a self-send deadlock hazard on a full channel. Since the manager has already performed the removal, mark the old device's disconnect as notified before disconnecting so no stale event is queued. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The stop-ack rework regressed two deduplication layers, causing stop commands on multi-feature devices to emit spurious intermediate-state writes (836-case device protocol suite: 138 failures): - The device task's acknowledged-flush path skipped overlaps() dedup when the pending queue was empty. A multi-feature stop accumulates one full-state write per feature in a single message; only the final state may reach hardware. - The stop path called the protocol handler directly, bypassing the last-output-command equality check. Stop commands matching a feature's current state must generate no writes, and stops must update the map. Both restore the exact semantics of the pre-rework implementation via a shared output_cmd_hardware_commands helper. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vergen 10 exposes Build and Gitcl through their associated builder methods rather than exporting the generated builder types. Update the build script to use the supported API while preserving build timestamp and Git SHA emission.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <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
8 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.
No description provided.