buttplugio / buttplug-rs-ffi Goto Github PK

Feature Description

To be able to quickly check whether ButtplugClient is connected to intiface or not.

Calling StartLogHandler() will crash due to the delegate not having a living local reference, so the GC gets mad.

Describe the bug

1. Load buttplug WASM in a webpage on chrome
2. Try scanning without a user gesture (on load, setTimeout, etc)

Expected behavior
"User gesture missing" exception is thrown to the top, promise rejects

Actual behavior
Promise resolves wihtout issue, but no scanning dialog.

Feature Description

Devices now have raw message capabilities in Buttplug v0.10. Need to expose these to the currently implemented layers.

• Rust FFI
• C#
• WASM

Since Websockets are built in via web-sys, we only get a JsValue back. I'm being lazy at the moment while fixing #38 and just throwing a string back up through our stack that gives a vague idea of what would be wrong, but it'd be nice if we could somehow get more info into that string than just "url is wrong" or "Server ain't there".

ButtplugClient:ScanningFinished -> Does not appear to fire when a scan is stopped/finished.
ButtplugClient:ServerDisconnect -> Does not appear to fire when the intiface websocket server is shut down.

It could be my code, but I don't think I've done anything unorthodox.
https://github.com/kyrahabattoir/ToyWebBridge/blob/master/Services/WebsocketService.cs#L112

It's unclear what's the intended behavior is, but I would have assumed SendVibrateCmd without any additional parameters to vibrate all available motors. This seems to be a regression from the old C# API, which would do this.

https://github.com/buttplugio/buttplug-csharp/blob/40713a450e8224ac408ad4175f75b6f19b915cb8/Buttplug/Client/ButtplugClientDevice.cs#L208

Feature Description

Add ability to use the websocket client to connect via FFI.

Should put in steps to see whether bluetooth capabilities are present or available, and relay this to the user.

We need to be able to generate documentation for each FFI implementation, but this may vary depending on the tools available for the language in question

• Core FFI
• WASM
• C#
• Python
• Java
• C

Due to the connect call now returning a fully formed client, javascript listeners can't set up event handlers before connect, meaning they'll miss device added, disconnect, etc... events.

Feature Description

We can add listeners but can't remove them. Need to add this to make API surface similar to node's EventListener.

Feature Description

Allow choosing comm managers for the in-process connector. There's already a flatbuffer enum, just need to hook everything up.

Expected behavior
flag on client should change to false because scanning has stopped.

Actual behavior
it's still true

Additional context
browser

Trying to use devices whose protocols have futures_timer Delay calls in them will panic the WASM library, as timer methods are not directly translatable in web-sys. This may require forking wasm_timer, which works but causes symbol conflicts in web-sys due to using an older version than ours.

Check out https://github.com/Polidea/react-native-ble-plx, see if that would work for integrating BP with react native

Feature Description

Devices currently do not send MessageAttributes when created, nor is there a way to access them.

• Rust FFI
• C#
• WASM

Copypasta error, doing wrong message type check on LinearCmd commands.

For Python, will we be distributing the library with the PyPi package, or expecting the user to provide it somehow?

We should be able to support multiple platforms in our C# nuget package. However, this will require runtime platform detection and loading, which is going to be interesting to deal with.

Checklist for finished platforms:

• Windows x64
• Windows x32
• Linux x64
• Linux ARM (RPi)
• macOS x64
• macOS ARM/M1

We'll need two FFI layers for buttplug-rs-ffi in JS:

• WASM, which is already handled via wasm-bindgen and our bindings in this repo
• Neon, which we'll use for native bindings to node

For the past 3 years, we've distributed both the node module and webpack'd web module in the "buttplug" package on npm. This is now more complicated, since the WASM library will be all of Buttplug + web components (WebBluetooth, Browser websockets, etc), and the node will be neon bindings. So we need to decide whether we're shipping everything in the same package (if that's even possible?), or splitting to buttplug-web and buttplug-node and deprecating our main package.

Currently we just forward log messages as a JSON formatted string over to an FFI impl. Ideally, this should be a pbuf object. We can start this by just using serde to turn the json back into a rust object that then becomes a pbuf, but the true solution is to write a tracing formatter that actually kicks out the pbuf log object we want.

Once we move C#'s nuget package to the rust implementation, we'll need to redistribute it with multiple builds on the rust library, for each platform and architecture. Not quite sure how this is going to work yet.

Feature Description

The C# library only builds for .Net Standard at the moment, which makes Unity angry sometimes when linking. Should try making a .Net Framework version too.

Feature Description

It'd be nice for other language implementations to be able to use test devices somehow.

Feature Description

Need to be able to retrieve device index from a WASM ButtplugClientDevice.

Came in with Buttplug-rs v0.9

Someone with a fussy on-board bluetooth radio reported a stack that had a panic in the WebBluetoothDevice write() method.

panicked at 'called `Option::unwrap()` on a `None` value', src\wasm\webbluetooth_device.rs:126:53

This was most likely an honest failure to write, but we shouldn't unwrap Nones there, we should return an error.

Describe the bug
With one or more device connected (hush/domi for me)

calling ButtplugClient::ConnectAsync ButtplugClient::DisconnectAsync ButtplugClient::ConnectAsync causes the following error:

Unhandled exception. System.ArgumentException: An item with the same key has already been added. Key: 1 at System.Collections.Generic.Dictionary 2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) at Buttplug.ButtplugClient.SorterCallback(UIntPtr buf, Int32 buf_length)

Expected behavior
There shouldn't be any error (unless we are ment to destroy the client object between connections?)

Actual behavior
Mentioned above.

Additional context
Buttplug-rs-ffi c# 1.0.5

Feature Description

To be able to quickly check whether ButtplugClient is currently scanning or not.

Given that there is already "Connected", maybe have a quad-state "Status" enum instead if a separate boolean? (disconnected/connecting/connected/scanning, 'connecting' because connection isn't instant and doesn't necessarily mean disconnected?).

I just can't think of a case where you would be scanning and also disconnected.

The WASM FFI layer is built much like buttplug-rs. The problem here is that we know there will never be more than one thread in the WASM FFI, it's impossible due to the JS execution model. This may mean we're over-complicating the API for reasons that aren't actually valid.

Need to swing back through and rethink some of this stuff.

The WASM/JS package loads protobufjs in content, but has it listed as a dev dependency. Need to turn that into an actual dependency.

Waiting for the next version of tracing, but will use tracing_subscriber::reload::Handle to hold a global (lazy_static) handle to the level. Just can't do this currently because of issues with generic types in statics, and don't want to create a holder object for it.

ToDo:

• Rust FFI
• C#
• WASM

Feature Description

FFI libs are somewhere between binaries and libraries, so probably best to treat them like applications and actually freeze the lock files so we can make sure the release versions all build against what we expect.

The in-browser websocket connector for WASM doesn't properly bubble errors if a connection fails.

• Rust FFI
• C#
• WASM

Feature Description

The FFI layers will be used for both in-process and client only libraries. Need to set up features to handle this. The external FFI API will stay the same, but will error when trying to connect with an in-process connector.

Feature Description

Emit all server events from FFI layer.

Todo:

• Rust FFI
• C#
• WASM

Add ability to register a callback whenever tracing emits a message. This should add an extra layer to the tracing registry to run callback per log message (with level).

Feature Description

Need to be able to load alternative configurations for the DeviceConfigManager.

Describe the bug
A clear and concise description of what the bug is. Remember, this should only pertain to bugs at the protocol or general architecture level. Library or application specific bugs should be files in their respective repos.

Expected behavior
https://buttplug-js.docs.buttplug.io/classes/buttplugclientdevice.html#allowedmessages

Actual behavior
console.dir(device.AllowedMessages)

Need a test executable that will:

• Add a special test device manager we control, to monitor device access
• Bring up a server
• Expect a certain chain of commands to be run from the FFI client to the server, to check functionality
• On client disconnect, will report methods that were not called

This would be handy for implementing new FFI implementations and giving a sort of "rosetta stone" approach for API creation.

Feature Description
I’ve read most of the public info on inteface and syncydync but am stil perplexed by how to develop with it. I’m currently working in Angular and would love to build out some example components which send static and dynamic messages to inteface for controlling video game contoller devices.

Would @qdot be willing to answer questions regarding standard connectivity and communication from the JS app?

I have a few ideas I’d like to build out and would give the work to your community of course.

Clear definition of the feature, possibly including any help you could provide on implementing this feature, or resources you would need help with implementation.

Feature Description

Returning errors from WASM at the moment just turns them into untyped strings. It'd be nice if they at least turned into their error class types.

Feature Description

See buttplugio/buttplug#156.

• Rust FFI
• C#
• WASM

Came in with buttplug-rs v0.9

• Rust FFI
• C#
• WASM

C# address is currently hardcoded. Should fix that.

Feature Description

Needed for matching buttplug-js API surface.

Came with buttplug-rs v0.9

• Rust FFI
• C#
• WASM