Skip to content

Conversation

Shatur
Copy link
Contributor

@Shatur Shatur commented Oct 7, 2025

Objective

bevy_input provides primitives for all kinds of input. But on consoles you usually don't have things like touch. On more obscure platforms, like GBA, only gamepad input is needed.

Solution

To avoid including extra stuff, I put each source under a feature. I didn't enable them by default to avoid typing

default-features = false, features = [
    "std",
    "bevy_reflect",
    "bevy_ecs/async_executor",
    "smol_str"
]

in all places that include bevy_input. Instead, I just enabled the used input sources in bevy_window and bevy_gilrs. This way, when a crate that provides hardware support for a specific input source is not used, the corresponding feature in bevy_input also won't be enabled.

For GBA this reduced the binary size for the game example from 1.6M to 1.4M.

Considered alternatives

I also considered doing something like this:

pub struct InputPlugin {
    pub keyboard: bool,
    pub mouse: bool,
    pub gamepad: bool,
    pub touch: bool,
}

But this doesn't eliminate extra code even with LTO enabled and might be confusing for users, since toggling these values could cause a crash due to a missing resource when a crate like bevy_window expects it.

`bevy_input` provides primitives for all kinds of input. But on
consoles you usually don't have things like touch. On more obscure
platforms, like GBA, only gamepad input is needed.

To avoid including extra stuff, I put each source under a feature.
I didn't enable them by default to avoid typing

```toml
default-features = false, features = [
    "std",
    "bevy_reflect",
    "bevy_ecs/async_executor",
    "smol_str"
]

in all places that include `bevy_input`. Instead, I just enabled
the used input sources in `bevy_window` and `bevy_gilrs`. This way,
when a crate that provides hardware support for a specific input
source is not used, the corresponding feature in `bevy_input` also
won't be enabled.

For GBA this reduced the binary size for the game example from
1.6M to 1.4M.
@alice-i-cecile alice-i-cecile added A-Input Player input via keyboard, mouse, gamepad, and more C-Usability A targeted quality-of-life change that makes Bevy easier to use M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide X-Controversial There is active debate or serious implications around merging this PR O-Embedded Weird hardware and no_std platforms labels Oct 7, 2025
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this change. That space savings is nothing to sneeze at on embedded, and this feels like the cleanest way to do this. Some platforms / projects genuinely don't need various input modes.

The features aren't set up quite right: you need descriptions over each individual feature and then you'll need to regenerate a file. See #21434 for details.

in all places that include bevy_input. Instead, I just enabled the used input sources in bevy_window and bevy_gilrs. This way, when a crate that provides hardware support for a specific input source is not used, the corresponding feature in bevy_input also won't be enabled.

I was expecting default features to be enabled for these, but your explanation here makes sense and seems fine to me.

Oh and this also needs a solid migration guide: changes to features are really hard to debug!

@alice-i-cecile alice-i-cecile added the S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged label Oct 7, 2025
@Shatur
Copy link
Contributor Author

Shatur commented Oct 7, 2025

Yep, I'm already working on all of these!

@Shatur Shatur requested a review from alice-i-cecile October 7, 2025 18:20
@Shatur Shatur removed the S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged label Oct 7, 2025
@alice-i-cecile alice-i-cecile added the S-Needs-Review Needs reviewer attention (from anyone!) to move forward label Oct 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Input Player input via keyboard, mouse, gamepad, and more C-Usability A targeted quality-of-life change that makes Bevy easier to use M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide O-Embedded Weird hardware and no_std platforms S-Needs-Review Needs reviewer attention (from anyone!) to move forward X-Controversial There is active debate or serious implications around merging this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants