1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
//! Motion-sensor hardware backends (gyroscope / accelerometer).
//!
//! Separate from [`crate::gamepad`] on purpose: a sensor driver reads devices
//! only for their IMU, leaving buttons, axes and rumble to the gamepad
//! backend. Keeping the traits apart means no driver has to claim both.
//!
//! Linux reads `/dev/input/event*` directly (`evdev`, `sensors` feature),
//! because motion never reaches gilrs. The input protocol gives it a precise
//! shape: a node flagged `INPUT_PROP_ACCELEROMETER` reports accelerometer data
//! on its directional axes (`ABS_X/Y/Z`) and gyroscope data on its rotational
//! axes (`ABS_RX/RY/RZ`), and must not mix them with regular stick axes. Each
//! axis `AbsInfo` resolution is counts per unit, so `value / resolution` is g
//! and degrees per second.
//!
//! Every mainline driver (hid-steam, hid-playstation, hid-nintendo,
//! hid-sony) puts motion on its own node named after the pad, so readings
//! carry the pad's name for the runner to resolve to a
//! [`GamepadId`](repose_core::input::GamepadId).
use SensorSample;
pub use ;
/// One reading tagged with the hardware device that produced it. The runner
/// resolves `device` against the connected pads' names, so backends never
/// assign pad ids themselves.
/// Hardware poller for motion sensors. Default: no sensors.
/// Placeholder backend for targets without a motion driver yet.
;
/// Create the platform sensor backend, or `None` when `sensors` is off or the
/// target has no motion driver yet.