XInput: Comments on core and further steps

[Juan Jose Gonzalez]

On 02/14/2016 06:27 PM, Stefan Dösinger wrote:
> Is the idea of xinput.dll still to talk to Xbox gamepads only, or did
> Microsoft change that at some point? If it's Xbox only you have the
> option to just do the same thing and keep our implementation limited
> to one piece of hardware. This approach has obvious drawbacks, but it
> might be easier to get an implementation started this way.
>
No, as far as I know Microsoft didn't change anything, although there
are several pieces of software that implement the XInput interface,
replacing the xinput dlls, while mapping inputs from HID or other devices.

When it comes to drivers, Xbox controllers aren't HID devices, but use
their own protocol. Under linux, the evdev interface (ie. standard input
interface) for Xbox controllers is implemented via the xpad module in
kernel space or the xboxdrv daemon in userspace, *not* the usbhid
module. If we were to limit wine's XInput support to Xbox controllers,
then the proper way would be to implement something similar to the
xboxdrv project (https://github.com/xboxdrv/xboxdrv) as an XInput
backend to directly access the controllers.

Due to the nature of WINE, I believe that limiting ourselves to Xbox
controllers is not acceptable, even if Microsoft's XInput only accepts
those. I think we should allow mapping any controller to XInput to
improve the usability. Nevertheless, we could start by providing
mappings for XBox controllers and other popular controllers and, after
that is solid, implement a GUI to allow the user to add additional
mappings. This is actually what I've done for the evdev backend (not the
GUI part, but the predefined list of mappings for Xbox controllers).