windows: HID raw input for gamepads and joysticks

[valaphee]

This PRs goal is to add rudimentary gamepad and joystick support through device events (Motion and Button) and therefore don't require button/axis mapping as they are device dependent.

It's loosely based on #1969 and relatively lightweight.

While looking through previous work I noticed that xinput was also considered as device input, which is wrong as they should be mostly unfiltered, like with raw input.

On web there is no raw input logically, but should it still be exposed through device events?

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[valaphee]

It might be worth to add some way to of identification in the device added message, as at the moment its not possible to know if its a keyboard, mouse, joystick, etc. and maybe what product was attached.

Don't know if I should add this in this pr, as it would affect all targets.

[daxpedda]

We have discussed this in todays meeting and we still need to do more research for some platforms, but the current discussion revolves around the fact that we need a common type for device IDs for all backends.

In general this will need some more design work first!

[valaphee]

This PR just extends on the already existing capabilities. A proper gamepad and joystick API should definitely have stable device ids (for hotplug), way to control rumble, or more device specific, leds etc. and map the buttons (which requires definitions), but idk if this should be in winit.

The better approach would be to use the most high-level api on the platform, like on Windows just use WGI (which is also better for Xbox support, and HID report parsing is sometimes inaccurate), X11 or Wayland would still require custom mapping, Web theoretically not.

[daxpedda]

So right now we came to the conclusion that all backends (except Windows) can do this without any help from Winit at all.

@msiglreith would be great if you could clarify if that applies to Windows as well.

[msiglreith]

@daxpedda should be possible on Windows as well, just need to create an additional hidden window same as the current EventLoop implementation.

[daxpedda]

@daxpedda should be possible on Windows as well, just need to create an additional hidden window same as the current EventLoop implementation.

I would consider that if this doesn't work without creating an empty hidden window, it should indeed live in Winit. My assumption here is that this would otherwise introduce not insignificant overhead and would probably need a separate thread?

So this leaves us with three ways to move forward here:

1. Cross-platform event.
2. Platform-specific event for Windows only (and maybe for X11 temporarily as well).
3. Push towards external integration with the event loop by the user.

I'm currently leaning towards 1.

[valaphee]

Adding RawInput also just extends the already existing infrastructure, that's why I found it a good idea to add it here.

Even though this api is also not that flexible, because with using raw input directly, you can also use device specific features, as you recv and send raw hid reports.
But the same functionality can also be achieved on Windows with https://github.com/ruabmbua/hidapi-rs without significant overhead.

This API is also not that useful on its own as some devices have different analog ranges, completely different button mappings, etc. (that's why SDL2 mappings exist)
But DeviceEvents are expected to be raw anyway.

Either way, gamepad handling is not really a requirement as external crates just work fine. But it would make sense to integrate into existing apis, like emitting DeviceEvents and building a proper gamepad api, etc. (with mapping)

[daxpedda]

Either way, gamepad handling is not really a requirement as external crates just work fine. But it would make sense to integrate into existing apis, like emitting DeviceEvents and building a proper gamepad api, etc. (with mapping)

Our current stance has been to leave it to external implementations as long as its possible.
So I don't believe we are going to go further then just emitting HID addition/removal here.

[Frankkkkk]

Hi @daxpedda , Would it be possible to show a simple example (or point to a repo that uses them) of HID events as an external impl.? That would be awesome; thanks!