Struct HapticRequest 

#[repr(C)]
pub struct HapticRequest {
    pub pattern: HapticPattern,
    pub target: HapticTarget,
    pub intensity: f32,
    pub duration_ms: u32,
}

A queued haptic request.

Queued rather than played synchronously because a callback runs on the layout thread, and the platform APIs that drive actuators want to be called from the event loop — the same reason clipboard writes and menu opens are deferred.

Fields

pattern: HapticPattern

target: HapticTarget

intensity: f32

Strength scale in 0.0..=1.0, where 1.0 is the platform’s own default strength for the pattern.

Portable because three of the four backends take a scale natively: Android’s composition primitives take a float scale, iOS’s impactOccurred(intensity:) takes one, and gamepad rumble IS an amplitude. macOS is the exception — NSHapticFeedbackPattern has no strength axis at all, so the value is ignored there rather than emulated, because faking it with repeated taps feels like a stutter.

duration_ms: u32

How long the effect should last, in milliseconds. 0 means “the pattern’s own natural duration”, which is what every tap-style actuator wants.

Only meaningful for continuous actuators — gamepad rumble motors, which run until told to stop. Tap-style actuators ignore it.

Implementations

impl HapticRequest

pub const fn new(pattern: HapticPattern, target: HapticTarget) -> Self

A request at full strength and natural duration — the common case.

pub fn intensity_clamped(&self) -> f32

Clamp the scale into the range every backend assumes.

Callers compute intensity from things like drag velocity, so an out-of-range or NaN value is expected rather than exceptional; a NaN reaching Android’s addPrimitive throws.

pub fn rumble_duration_ms(&self) -> u32

How long a CONTINUOUS actuator should run, in milliseconds.

duration_ms == 0 means “the pattern’s natural duration”, which for a tap-style actuator is whatever the platform does and for a MOTOR is not zero: a rumble of zero length is not something a person can feel. 150ms is gilrs’s own example figure and about the shortest pulse an ERM motor can spin up and down within.

Shared rather than repeated per backend: the gilrs path and the Android per-controller vibrator answer the same question, and two copies of a magic number drift.

pub fn wants_strong_motor(&self) -> bool

Which MOTOR this pattern belongs on, not how hard to drive it.

A controller has a low-frequency motor that THUDS and a high-frequency one that BUZZES, and the pattern picks between them. Driving both together is a different, muddier sensation rather than a louder one - which is why this is a bool and not a mix.

true = the strong (low-frequency) motor.

pub fn amplitude_u8(&self) -> u8

The intensity as an 8-bit amplitude in 1..=255.

Android’s VibrationEffect.createOneShot takes amplitude in that range, where 0 is not “silent” but INVALID - it throws IllegalArgumentException. A caller that wants silence must not play at all, so this floors at 1 and the backend checks for a zero intensity before calling.

Trait Implementations

impl Clone for HapticRequest

fn clone(&self) -> HapticRequest

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for HapticRequest

impl Debug for HapticRequest

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl PartialEq for HapticRequest

fn eq(&self, other: &HapticRequest) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for HapticRequest