Expand description
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.
Structs§
- NoSensor
Backend - Placeholder backend for targets without a motion driver yet.
- Sensor
Reading - One reading tagged with the hardware device that produced it. The runner
resolves
deviceagainst the connected pads’ names, so backends never assign pad ids themselves.
Traits§
- Sensor
Backend - Hardware poller for motion sensors. Default: no sensors.
Functions§
- create_
backend - Create the platform sensor backend, or
Nonewhensensorsis off or the target has no motion driver yet.