Expand description
Serializable device-model types.
These mirror the HID++ types from the hidpp crate but live here so the
CLI and any future GUI can depend on them without dragging in the protocol
crate or its async transport.
Structs§
- Battery
Info - Capabilities
- What a device can be configured to do, derived from the HID++ feature
table it reports (feature
0x0001). This is the source of truth for which configuration panels the UI offers — a panel shows iff the device exposes the feature that drives it. Gating on capability rather than onDeviceKindis what keeps a misclassified device from losing its panels (issue #127): kind is an identity guess, capability is what the firmware actually announced. - Device
Inventory - Device
Model Info - HID++
DeviceInformation(feature 0x0003) snapshot used to identify a device against external registries (e.g. the OpenLogi asset index). - Device
Transports - Mirror of hidpp’s
DeviceTransportbitfield — one bool per protocol the device firmware exposes. The shape is dictated by HID++ feature 0x0003; a state machine doesn’t fit since a single device can announce multiple transports simultaneously. - Paired
Device - Receiver
Info
Enums§
- Battery
Level - Coarse battery bucket reported by the device firmware.
- Battery
Status - Charging state. Mirrors
hidpp 0.2’sBatteryStatusplusUnknownfor values added in future protocol versions. - Device
Kind - What a paired peripheral is. Mirrors
hidpp::receiver::bolt::BoltDeviceKindbut is owned by us so consumers don’t depend onhidpp.