In light of wayland's requirement that winit participate in the raw input stack (see also the more mature relative pointer motion spec), DeviceEvent and its generic axis/button cases are being retained. On non-wayland platforms, however, winit is not required to, and currently does not, participate in the raw input stack for non-mouse/keyboard devices. We could:

• Continue to only involve winit in input handling on each platform only as much as that platform requires.
  This keeps winit smaller, and forces portable downstream code that wants non-mouse/keyboard input to involve an external crate for unhandled inputs and process events from both sources.

• Involve winit in input handling on all platforms for every device class for which winit is required to be involved on any platform
  This would mean communicating with evdev (for actual input) and udev (for hotplug support) on Linux, for example.

I think the strongest arguments for such an expansion in scope are consistency and ease of use. If a developer on Wayland someday writes a gamepad-using application on top of winit, they will be frustrated to find that it doesn't work on other platforms. On the other hand, if/when good dedicated crates exist they may not be difficult to drop in, and can presumably no-op on Wayland, removing the need for an application developer to write platform-specific code. DeviceEvent documentation could recommend this pattern, hopefully reducing potential for surprise.

Because Wayland is (afaik) the only platform where winit must be involved, and hasn't yet even adopted the direct input extension, the potential for surprise will remain very low for the near future: everyone already needs external code to handle non-mouse/keyboard input. As such, this is a low priority issue.