Consider expanding scope of raw input

[Ralith]

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.

[francesca64]

So, among other things, this would ostensibly give winit (low-level) gamepad support?

I'm not happy with the current state of DeviceEvent, i.e. when ggez migrated to winit I had to break the bad news about how the axis/button stuff wasn't useful. I also think people don't understand the rationale of DeviceEvent in general, so it could use a power-up.

Extending raw input in this fashion on Windows would be trivial. Like, I already have nice wrapper functions for all the calls. Broader unix support is a pain, but it's not like I'm not used to it.

While expanding winit's scope is a dangerous game, I'm not sure how avoidable it is. The owner of gilrs considered raw input support on Windows as out of scope, since it requires a window (they're still device events, but you need a window to receive the messages). While some integration could be worked out, just implementing it in winit would be quite easy.

[Ralith]

So, among other things, this would ostensibly give winit (low-level) gamepad support?

Basiclaly yes, although "gamepad support" is a dangerously narrow notion. Input devices are diverse, and while gamepads are common, they are only one form out of many possibilities.

Possibly of interest is the ongoing development of OpenXR, which as part of a broader goal to provide a forwards-looking abstraction for VR hardware, has proposed a potentially universal input API. Details can be found in the GDC presentation. If that works out, demand for support for the various eccentric platform APIs may be substantially reduced.

[wackbyte]

+1 for OpenXR

[Ralith]

OpenXR has unfortunately ended up being very VR specific, which makes it pretty much orthogonal to winit. A more general API could be developed that encompasses conventional applications on similar principles, but I'm not sure winit could rely on that in lieu of broad support from platform vendors, which is unlikely.