I can't work on fixing the unit tests until this is fixed:

error[E0599]: no method named `to_string` found for reference `&str` in the current scope
   --> crates\bevy_ecs\src\name.rs:252:24
    |
252 |         Ok(Name::new(v.to_string()))
    |                        ^^^^^^^^^ method not found in `&str`
    |
    = help: items from traits can only be used if the trait is in scope
help: trait `ToString` which provides `to_string` is implemented but not in scope; perhaps you want to import it
    |
3   + use crate::alloc::string::ToString;

For the alloc error, I think you need to fix the feature flags in a new PR. @bushrat011899, FYI.

For the alloc error, I think you need to fix the feature flags in a new PR. @bushrat011899, FYI.

He's already got that fixed in the no_std bevy_input PR.

Can confirm I have this issue resolved in the no_std bevy_input PR, along with some other issues with how bevy_input feature gates bevy_reflect

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

Let's do a quick migration guide noting this change (since it's otherwise surprising), but this LGTM now. Good work on the tests; I like the balance you struck.

Sorry for the noise. I realized that I could make the implementation and test data cleaner by storing the raw values in the gamepad, which means the old values will be raw values. Everything is very optimal now, imo.

Migration guide made me realize the doc comment should be improved. Both are done now.

Personally, I think deadzone is a more high-level functionality and should be handled by input managers

Agreed. In the medium term, I think this functionality should be removed from bevy_input and moved up a level. But until we have a first party input manager / action crate we're blocked there.

I think deadzones and scaling are good here because they address hardware limitations. Before then, the events are "raw". The part I would move into another crate is actually the clamping/rounding. Those are more about what "feels right". But then again, the same applies for the press/release/change thresholds, and I don't think those can be moved out.

I would consider bevy_input as a source for raw input and its processing being a higher-level abstraction. That's what I currently do with my crate (I use methods that return raw values and let user apply any modifiers on top of them).

We on the same page with @alice-i-cecile, this PR is good.
I just wanted to share my thoughts for possible future considerations.

I'm choosing to not split up the unit test. It can be done as an improvement in a separate PR if someone would like. :)