buttplug.io
fork
Configure Feed
Select the types of activity you want to include in your feed.
Buttplug sex toy control library
fork
Configure Feed
Select the types of activity you want to include in your feed.
chore: Comment out Handy initialization that never ran
qdot.tngl.sh
+21
-19
+21
-19
buttplug/src/server/device/protocol/thehandy/mod.rs
+21
-19
buttplug/src/server/device/protocol/thehandy/mod.rs
···
16
16
},
17
17
server::device::{
18
18
configuration::ProtocolAttributesType,
19
-
hardware::{Hardware, HardwareCommand, HardwareReadCmd, HardwareWriteCmd},
19
+
hardware::{Hardware, HardwareCommand, HardwareWriteCmd},
20
20
protocol::{
21
21
generic_protocol_initializer_setup,
22
22
ProtocolHandler,
···
50
50
impl ProtocolInitializer for TheHandyInitializer {
51
51
async fn initialize(
52
52
&mut self,
53
-
hardware: Arc<Hardware>,
53
+
_hardware: Arc<Hardware>,
54
54
_: &ProtocolDeviceAttributes,
55
55
) -> Result<Arc<dyn ProtocolHandler>, ButtplugDeviceError> {
56
+
// Ok, somehow this whole function has been basically a no-op. The read/write lines never had an
57
+
// await on them, so they were never run. But only now, in Rust 1.75/Buttplug 7.1.15, have we
58
+
// gotten a complaint from the compiler. Going to comment this out for now and see what happens.
59
+
// If we don't get any complaints, I'm going to have to rewrite all of my snark here. :(
60
+
56
61
// Ok, here we go. This is an overly-complex nightmare but apparently "protocomm makes the
57
62
// firmware easier".
58
63
//
···
67
72
// First we need to set up a session with The Handy. This will require sending the "security
68
73
// initializer" to basically say we're sending plaintext. Due to pb3 making everything
69
74
// optional, we have some Option<T> wrappers here.
70
-
let session_req = protocomm::SessionData {
71
-
sec_ver: protocomm::SecSchemeVersion::SecScheme0 as i32,
72
-
proto: Some(protocomm::session_data::Proto::Sec0(
73
-
protocomm::Sec0Payload {
74
-
msg: protocomm::Sec0MsgType::S0SessionCommand as i32,
75
-
payload: Some(protocomm::sec0_payload::Payload::Sc(
76
-
protocomm::S0SessionCmd {},
77
-
)),
78
-
},
79
-
)),
80
-
};
75
+
76
+
// let session_req = protocomm::SessionData {
77
+
// sec_ver: protocomm::SecSchemeVersion::SecScheme0 as i32,
78
+
// proto: Some(protocomm::session_data::Proto::Sec0(
79
+
// protocomm::Sec0Payload {
80
+
// msg: protocomm::Sec0MsgType::S0SessionCommand as i32,
81
+
// payload: Some(protocomm::sec0_payload::Payload::Sc(
82
+
// protocomm::S0SessionCmd {},
83
+
// )),
84
+
// },
85
+
// )),
86
+
// };
81
87
82
88
// We need to shove this at what we're calling the "firmware" endpoint but is actually the
83
89
// "prov-session" characteristic. These names are stored in characteristic descriptors, which
···
90
96
//
91
97
// If they ever change this, I quit (or will just update the device config).
92
98
93
-
let mut sec_buf = vec![];
94
-
session_req
95
-
.encode(&mut sec_buf)
96
-
.expect("Infallible encode.");
97
-
hardware.write_value(&HardwareWriteCmd::new(Endpoint::Firmware, sec_buf, false));
98
-
let _ = hardware.read_value(&HardwareReadCmd::new(Endpoint::Firmware, 100, 500));
99
+
// hardware.write_value(&HardwareWriteCmd::new(Endpoint::Firmware, sec_buf, false));
100
+
// hardware.read_value(&HardwareReadCmd::new(Endpoint::Firmware, 100, 500));
99
101
100
102
// At this point, the "handyplug" protocol does actually have both RequestServerInfo and Ping
101
103
// messages that it can use. However, having removed these and still tried to run the system,