Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Mizz Zee v2.1 protocol #602

Closed
wants to merge 12 commits into from

Conversation

SuhEugene
Copy link
Contributor

@SuhEugene SuhEugene commented Jan 6, 2024

I implemented it as a new protocol because I'm afraid of breaking something that already exists.

This is my first time using Rust so I'm sorry for making your eyes bleed.

Protocol documentation:

@SuhEugene SuhEugene changed the base branch from master to dev January 6, 2024 19:37
Copy link
Member

@qdot qdot left a comment

Choose a reason for hiding this comment

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

@blackspherefollower is the final reviewer on this 'cause they handle all of our device code, just figured I'd add my thoughts for using atomics since these are sinple integer types.

buttplug/src/server/device/protocol/mizzzee_v2_1.rs Outdated Show resolved Hide resolved
@blackspherefollower
Copy link
Collaborator

I might not get in front of a real keyboard until tomorrow, but the big thing I think wants changing is that the vibrate command handler should probably return the new vibration command after setting it for the loop. That way you don't have to do any of the last value checking in the loop and the loop can sleep longer and use fewer cycles.

@blackspherefollower
Copy link
Collaborator

I might not get in front of a real keyboard until tomorrow, but the big thing I think wants changing is that the vibrate command handler should probably return the new vibration command after setting it for the loop. That way you don't have to do any of the last value checking in the loop and the loop can sleep longer and use fewer cycles.

I got to a keyboard!

I also happened to receive a new metaXsire device with a very similar command pattern, that's got a lot of the same repeating pattern: e6ef63f#diff-4fe286dab6c3ad0e0859445fcfdd7c65df07182b80998fe850f936451b0cf2f0

@blackspherefollower
Copy link
Collaborator

@qdot I think my comments are all addressed within reason. I think this can probably land.

@SuhEugene SuhEugene requested a review from qdot January 9, 2024 09:44
@blackspherefollower
Copy link
Collaborator

@SuhEugene FYI my hardware has arrived, so I'm able to test now, and I don't think this is behaving as expected: it feels like there's weird lag (like it's not always stopping) and worse, when I restart my test app after controlling the hardware but not restarting the device, it ignores commands outright.

Did you see anything like this in your testing?

@blackspherefollower
Copy link
Collaborator

@qdot I squashed this PR + the final tweaks to work properly with my model into 4ef4247

@SuhEugene
Copy link
Contributor Author

Squashed into 4ef4247 of #603

@SuhEugene SuhEugene closed this Jan 20, 2024
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.

3 participants