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).