AprilNEA/OpenLogi · error

wheel resolution write not applied: requested

Error message

wheel resolution write not applied: requested {}, device reports {}

What it means

Raised by the wheel (scroll resolution) diagnostic after `set_scroll_resolution` writes a requested resolution and reads the reporting state back: `after.resolution` differs from `requested`. The transport accepted the write but the device does not report the requested scroll resolution, so the diagnostic fails rather than claiming success. Values are rendered via `resolution_label` in the message.

Solutions

  1. Clamp the requested resolution to the device's supported resolution set before writing.
  2. Retry the write — the set command may have been lost on the wireless link.
  3. Verify the wheel reporting target is Native before/when writing so the write reaches the right control.
  4. Check firmware support for the exact resolution step on this model.

Example fix

// before
anyhow::bail!(
    "wheel resolution write not applied: requested {}, device reports {}",
    resolution_label(requested),
    resolution_label(after.resolution)
);
// after
let requested = nearest_supported_resolution(&route, requested).await?;
if after.resolution != requested {
    anyhow::bail!(
        "wheel resolution write not applied: requested {}, device reports {}",
        resolution_label(requested),
        resolution_label(after.resolution)
    );
}
Defensive patterns

Strategy: validation

Validate before calling

// Only request resolutions the device actually supports
let supported = device_supported_scroll_resolutions(&route).await?;
let requested = supported.iter().copied().min_by_key(|r| (*r as i32 - wanted as i32).abs()).unwrap();

Try / catch

match set_scroll_resolution(&route, requested).await {
    Err(e) if e.to_string().contains("resolution write not applied") => {
        eprintln!("device reports {after:?}; falling back to nearest supported value");
    }
    other => other?,
}

Prevention

When it happens

Trigger: Running the wheel diagnostic with a requested resolution where the read-back `after.resolution != requested` — device clamped the value to its supported range, rejected the write, or the write went to the wrong reporting target.

Common situations: Requesting a DPI/ratchet value outside the device's supported scroll-resolution table; firmware silently snapping to the nearest supported step; flaky wireless link dropping the set command; writing while the reporting target is not the native HID++ control.

Related errors


AI-assisted analysis of AprilNEA/OpenLogi@e846e6f4b4 (2026-09-13). Data as JSON: /api/errors/4d7fd09d06cc5c02. Report an issue: GitHub.

Appendix: source

Thrown at crates/openlogi-cli/src/cmd/diag/wheel.rs:58

    let (route, name) = select_device(args.device.as_deref(), &[0x2121]).await?;
    println!("device: {name} ({route})");

    let before = openlogi_hid::get_scroll_wheel_mode(&route)
        .await
        .context("read HiResWheel mode")?;
    print_mode("current", before);

    let Some(requested) = args.resolution.map(ScrollResolution::from) else {
        return Ok(());
    };

    let after = openlogi_hid::set_scroll_resolution(&route, requested)
        .await
        .context("set wheel resolution")?;
    print_mode("read-back", after);

    if after.resolution != requested {
        anyhow::bail!(
            "wheel resolution write not applied: requested {}, device reports {}",
            resolution_label(requested),
            resolution_label(after.resolution)
        );
    }
    if after.target != ScrollReportingTarget::Native {
        anyhow::bail!(
            "wheel reporting target is not native after write: {:?}",
            after.target
        );
    }
    if after.inverted != before.inverted {
        anyhow::bail!(
            "wheel inversion changed unexpectedly: was {}, now {}",
            before.inverted,
            after.inverted
        );
    }

View on GitHub (pinned to e846e6f4b4)