Admin
Reboot a chip and return to passthroughBox-maintenance calls: reboot restarts one of the two chips, reset drops the box back to passthrough. Both are fire-and-forget: send one frame, no reply.
use medius::Device;
let device = Device::find()?; // first box on the system, handshake done
device.reset()?; // back to passthroughfind opens the first box; related calls reapply and reconnect are on the Lifecycle page.
reset
Clear all injection, return to passthroughfn reset(&self) -> Result<()>
Fire-and-forget
| State | What reset does |
|---|---|
| Box accumulator | Zeroed. This is the box's running total of injected motion and scroll not yet emitted to the PC. |
| Box overrides | All released. An override is a per-usage decision to hold an input down or up. |
| Library held-state | Cleared. The library forgets which overrides it was holding, so a later reapply or reconnect re-asserts nothing. |
Sends one RESET frame and clears the library's held state. Afterward the box behaves as if nothing was injected.
use medius::Button;
device.move_rel(40, 0)?; // nudge the cursor 40 right
device.press(Button::Left)?; // hold left down
device.release(Button::Left)?; // let it back up
device.reset()?; // drop all of the above, back to passthroughreboot
Restart or download-mode one of the two chipsfn reboot(&self, target: RebootTarget) -> Result<()>
Fire-and-forget
RebootTarget picks the chip and whether it comes back running its firmware or in download mode; the four variants and their bytes are on Types. See the native REBOOT command for the wire layout.
use medius::RebootTarget;
device.reboot(RebootTarget::DeviceRun)?; // restart the chip you're talking toA Download variant leaves the chip in ROM download mode: it stops acting as a mouse and stops answering until reflashed or power-cycled. Don't send one unless you're about to flash.
Rebooting the device chip drops the serial link, so the call can return Ok as the connection goes away. The reader thread auto-reconnects, or force it with reconnect.
The flash feature issues the download reboot for you, so you rarely send a Download variant by hand.
On AsyncDevice
Still fire-and-forget, no awaitAsyncDevice re-exposes reset and reboot unchanged: they expect no reply, so no .await and no block_on. Only the queries are async.
use medius::{AsyncDevice, RebootTarget};
let device = AsyncDevice::open("/dev/ttyACM0")?;
device.reset()?; // sync, no await
device.reboot(RebootTarget::HostRun)?; // sync, no await