Hi Juan,
Awesome thanks for this work. Know I am sure that to get this into wine will require a bit of work so hopefully you are will to go through the process of revisions with us to see things through.
On 2/14/16 7:22 AM, Juan Jose Gonzalez wrote:
Hi,
I just published a patch with my xinput core implementation. If anyone is interested in an evdev (linux) backend I could publish that too, but I guess it won't make it into wine due to the tendency towards the HID architecture.
Yeah, we will want to target the HID architecture and I can totally help you on that. I think it should be pretty straight forward. Looking at your back end interface code it all looks really pretty easy. There are parts you have around the mapping that I almost wonder if we want to move into that back end, or maybe a middle layer. I will have to spend more time reading the code before I can come up with anything concrete there.
A rough overview on how it's supposed to be used can be read in the README file from the second patch. Let me know what you think.
The next step would be to implement a backend that uses hid.dll. Using HID devices should be fairly straightforward. There are, however, two parts that I haven't figured out yet:
- How can we find new devices? The current work for the HID
architecture seems to have tackled the hotplugging problem. Can the XInput HID backend get notified when a new controller gets plugged in? Should it just poll for new devices using SetupDi functions or something similar?
There are 2 bits here, hotplugging and device detection. They are 2 separate processes. Speaking on device detection, I think the best thing for us to do would be the process of enumerating the devices via setupapi and selecting the appropriate ones, as you have pointed out with the SetupDi functions. I have code that does this for winejoystick.dev implementation of HID that I have been working on, not sent anywhere yet, and it is not a difficult process. I will attach my winejoystick.drv module for inspiration/example but it is clearly not ready to actually be submitted as a patch, if for no other reason that all the supporting HID work is not in place yet.
As for hot plugging that will come through plug and play processes that are still on the drawing board. Probably something eventually involving RegisterDeviceNotification once that gets some love.
- How do we map a controller's buttons and axes to the corresponding
XInput ones? This has to be done per controller model. My evdev backend has a lookup list that matches controllers to a certain mapping using some selection criteria (Name, Vendor ID, etc.). My idea was to load the mappings from the registry, but for this to be usable by regular users, a GUI would have to be implemented to create those registry entries.
I agree that mapping should be allowed for any appropriate controller and not restricting us to particular vendors. (Microsoft)
With HID we get Usages for all our elements. So what we will want to do is probably figure out what usages map to what control elements on an Xbox controller and have that be default mappings. (Here is the HID USB spec for usages http://www.usb.org/developers/hidpage/Hut1_12v2.pdf, windows HID matches these) so if the A button is page 0x9 Usage 0x1 then by default the element of 0x9 0x1 would be the A button. We would then want to be able to have a way to map other controllers. I am sure that existing controller maps exist, it would be nice if we could load/use them.
-aric